"Kirby Bohling (TRSi)" <kbohling(at)oasis(dot)novia(dot)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
In response to
- libpq bug at 2000-09-15 15:03:18 from Kirby Bohling (TRSi)
pgsql-bugs by date
|Next:||From: Christof Petig||Date: 2000-09-25 09:39:13|
|Subject: Re: Error with union in sub-selects|
|Previous:||From: Kirby Bohling (TRSi)||Date: 2000-09-15 15:03:18|
|Subject: libpq bug|