From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kirby Bohling (TRSi)" <kbohling(at)oasis(dot)novia(dot)net> |
Cc: | pgsql-bugs(at)postgreSQL(dot)org |
Subject: | Re: libpq bug |
Date: | 2000-09-15 19:20:57 |
Message-ID: | 136.969045657@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Ludovic LANGE | 2000-09-25 19:55:13 | PostgreSQL crashes using distance operator whith records where 'point' data type set to null |
Previous Message | Kirby Bohling (TRSi) | 2000-09-15 15:03:18 | libpq bug |