Re: libpq, threads and connection reset

pgsql-interface！

hello!

I have written database interface connnection class library on sybase, oracle .My project has built in the library. Now i will write the same library on postgresql, I need the same interface with oracle, thus I needn't modify my project. But i found postgresql interface is limited, for example , many out parameter, can't in a function . and in a function
i can't return many record, in libpqxx examples, there is not call function examples. can you help me?

　　　　　　　　致
礼！

　　　　　　　　cheng
　　　　　　　　ch_gang304(at)163(dot)net
　　　　　　　　　　2002-08-28

I'm having some problems with a multi-threaded application using libpq:

Some details:
OS: Solaris 2.6
Postgres version 7.2.1

When my application starts up the main thread (1) connects using PQsetdbLogin() which is successful
Another thread (5 for example) issues queries over this connection.

My test is stopping postgres (KILL -INT) and testing if my application detects the backend failure and
tries to re-connect.

Thread 5 issues a PQexec and discovers the error upon which thread 5 tries to reconnect (after calling PQfinish)
This reconnection HANGS, here is a stack trace:

ee037438 poll (ed906e48, 1, ffffffff)
ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac, ed908f2c, 4) + 280
ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8
ee695178 connectDBComplete (485e8, 0, ee0a3180, 0, efffebc0, ee086858) + f8
ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558

All access using the connection is serialized using a mutex.

I've tried the same test but with everything running in thread 1 and it works OK.

I've managed to spot some differences between the two tests:

Multi Threaded test:
The re-connect underlying call to connect returns -1 and sets errno to 146 (connection refused)

Single Threaded test:
The re-connect underlying call to connect returns -1 and errno = 0, so it thinks the connection is "in progress" and tries
to complete the connection - but hangs on the select (poll)

Any help or ideas greatly appreciated,

Joe

I'm having some problems with a multi-threaded application using libpq:

Some details:
OS: Solaris 2.6
Postgres version 7.2.1

When my application starts up the main thread (1) connects using
PQsetdbLogin() which is successful
Another thread (5 for example) issues queries over this connection.

My test is stopping postgres (KILL -INT) and testing if my application
detects the backend failure and
tries to re-connect.

Thread 5 issues a PQexec and discovers the error upon which thread 5
tries to reconnect (after calling PQfinish)
This reconnection HANGS, here is a stack trace:

ee037438 poll (ed906e48, 1, ffffffff)
ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac,
ed908f2c, 4) + 280
ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8
ee695178 connectDBComplete (485e8, 0, ee0a3180, 0, efffebc0,
ee086858) + f8
ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558

All access using the connection is serialized using a mutex.

I've tried the same test but with everything running in thread 1 and it
works OK.

I've managed to spot some differences between the two tests:

Multi Threaded test:
The re-connect underlying call to connect returns -1 and sets errno to
146 (connection refused)

Single Threaded test:
The re-connect underlying call to connect returns -1 and errno = 0, so
it thinks the connection is "in progress" and tries
to complete the connection - but hangs on the select (poll)

Any help or ideas greatly appreciated,

Joe

Sorry, a typo in my previous message see below....

Joe Murphy wrote:

> I'm having some problems with a multi-threaded application using libpq:
>
> Some details:
> OS: Solaris 2.6
> Postgres version 7.2.1
>
> When my application starts up the main thread (1) connects using
> PQsetdbLogin() which is successful
> Another thread (5 for example) issues queries over this connection.
>
> My test is stopping postgres (KILL -INT) and testing if my application
> detects the backend failure and
> tries to re-connect.
>
> Thread 5 issues a PQexec and discovers the error upon which thread 5
> tries to reconnect (after calling PQfinish)
> This reconnection HANGS, here is a stack trace:
>
> ee037438 poll (ed906e48, 1, ffffffff)
> ee04cc74 select (ed906e50, ed908ea8, ed908f28, ed908eac,
> ed908f2c, 4) + 280
> ee69e010 pqWait (0, 1, 485e8, 1, 81010100, ee0882cc) + 1d8
> ee695178 connectDBComplete (485e8, 0, ee0a3180, 0, efffebc0,
> ee086858) + f8
> ee69484c PQsetdbLogin (45e28, ed9091a2, 0, 0, 45d68, 45e40) + 558
>
> All access using the connection is serialized using a mutex.
>
> I've tried the same test but with everything running in thread 1 and it
> works OK.
>
> I've managed to spot some differences between the two tests:
>
> Multi Threaded test:

This should read "Single Threaded Test"

>
> The re-connect underlying call to connect returns -1 and sets errno to
> 146 (connection refused)
>
> Single Threaded test:

This should read Multi Threaded test

>
> The re-connect underlying call to connect returns -1 and errno = 0, so
> it thinks the connection is "in progress" and tries
> to complete the connection - but hangs on the select (poll)
>
> Any help or ideas greatly appreciated,
>
> Joe
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joe Murphy - AerSoft Limited
2 Northumberland Avenue, Dun Laoghaire, Co. Dublin.
phone: +353-1-2301166 direct: +353-1-2145953 fax: +353-1-2301167
mailto:joe(at)aersoft(dot)com mobile: +353-86-8526181 http://www.aersoft.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Joe Murphy <joe(dot)murphy(at)aersoft(dot)ie> writes:
>> The re-connect underlying call to connect returns -1 and errno = 0, so
>> it thinks the connection is "in progress" and tries
>> to complete the connection - but hangs on the select (poll)

Well, you have a bug in connect() if it's returning the wrong errno
in the multi-thread case.

However, our code in fe-connect.c reads like this:

if (connect(conn->sock, &conn->raddr.sa, conn->raddr_len) < 0)
{
if (SOCK_ERRNO == EINTR)
/* Interrupted system call - we'll just try again */
goto retry1;

if (SOCK_ERRNO == EINPROGRESS || SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == 0)
{
/*
* This is fine - we're in non-blocking mode, and the
* connection is in progress.
*/
conn->status = CONNECTION_STARTED;
}
else
{
/* Something's gone wrong */
connectFailureMessage(conn, SOCK_ERRNO);
goto connect_errReturn;
}

I wonder whether it's really a good idea to treat errno == 0 as
indicating "connection in progress". Does anyone know of a platform
where zero is actually what is returned in this case? The man pages
I can find all say that EINPROGRESS is returned.

regards, tom lane

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The problem I was having "went away" when I moved to another Solaris 2.6
machine with the latest patch level.
<br>I've also tested it on Solaris 8, HP-UX 11.00 and Linux, so it looks
like there is a connect bug in a release 2.6,
<br>but seems to be fixed with later patches.
<p>Thanks for the help.
<p>Joe
<p>Tom Lane wrote:
<blockquote TYPE=CITE>Joe Murphy &lt;joe(dot)murphy(at)aersoft(dot)ie> writes:
<br>>> The re-connect underlying call to connect returns -1 and errno =
0, so
<br>>> it thinks the connection is "in progress" and tries
<br>>> to complete the connection - but hangs on the select (poll)
<p>Well, you have a bug in connect() if it's returning the wrong errno
<br>in the multi-thread case.
<p>However, our code in fe-connect.c reads like this:
<p>&nbsp;&nbsp;&nbsp; if (connect(conn->sock, &amp;conn->raddr.sa, conn->raddr_len)
&lt; 0)
<br>&nbsp;&nbsp;&nbsp; {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (SOCK_ERRNO == EINTR)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* Interrupted system call - we'll just try again */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
goto retry1;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (SOCK_ERRNO == EINPROGRESS
|| SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == 0)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/*
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
* This is fine - we're in non-blocking mode, and the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
* connection is in progress.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
*/
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
conn->status = CONNECTION_STARTED;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* Something's gone wrong */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
connectFailureMessage(conn, SOCK_ERRNO);
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
goto connect_errReturn;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<p>I wonder whether it's really a good idea to treat errno == 0 as
<br>indicating "connection in progress".&nbsp; Does anyone know of a platform
<br>where zero is actually what is returned in this case?&nbsp; The man
pages
<br>I can find all say that EINPROGRESS is returned.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
regards, tom lane
<p>---------------------------(end of broadcast)---------------------------
<br>TIP 4: Don't 'kill -9' the postmaster</blockquote>

<pre>--&nbsp;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Joe Murphy - AerSoft Limited
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 Northumberland Avenue, Dun Laoghaire, Co. Dublin.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; phone: +353-1-2301166&nbsp;&nbsp;&nbsp;&nbsp; direct: +353-1-2145953&nbsp;&nbsp;&nbsp;&nbsp; fax: +353-1-2301167&nbsp;&nbsp;
&nbsp; <A HREF="mailto:joe(at)aersoft(dot)com">mailto:joe(at)aersoft(dot)com</A>&nbsp;&nbsp; mobile: +353-86-8526181&nbsp; <A HREF="http://www.aersoft.com">http://www.aersoft.com</A>&nbsp;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>
&nbsp;</html>