Skip site navigation (1) Skip section navigation (2)

Re: libpq bug

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 (view raw or flat)
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

In response to

  • libpq bug at 2000-09-15 15:03:18 from Kirby Bohling (TRSi)

pgsql-bugs by date

Next:From: Christof PetigDate: 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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group