Re: libpq bug

"Kirby Bohling (TRSi)" <kbohling@oasis.novia.net> writes:
> If you follow the code from the entry into PQexec, all that way into
> pqWait, and then down into the select call, I noticed that nowhere in the
> path of execution did it check conn->status to see if the status was
> CONNECTION_OK, it only checked to see if the socket non-negative.

Shouldn't matter --- the sock field is set to -1 whenever the connection
is closed.  Anyway, CONNECTION_BAD is a higher-level concept; I'm not
sure that pqWait should be looking at it.

> If my guess is correct, the backend has gone away, select can't tell that
> you are never going to be able to read or write on that socket.

Not true, at least not unless you are running atop a broken TCP stack.
A read wait on a socket that's been closed at the other end returns an
immediate EOF indication.

I'm not sure what's causing your problem, but I don't believe you've
identified the correct cause.  Have you looked at the postmaster log
to see what the backend thinks is happening?

> typedef struct pg_conn PGConn;
>
> Nice opaque typedef, but no way for me to print the structure in a
> debugger short of printing the raw memory.

Compile libpq with debugging symbols, and the debugger should know what
a PGConn looks like.

            regards, tom lane