Jeroen T. Vermeulen escribió: > On Thu, November 16, 2006 00:00, Leandro Lucarella wrote: >>> 2. The C API, libpq, gets an error return code on the next attempt to >>> use >>> the socket and handles it by noting that the connection has died. >> No, the C API, libpq, does not use MSG_NOPIPE when send()ing and >> recv()ing (I've checked the source code), so when the other end of the >> connection goes down, a SIGPIPE signal is sent to the process. > > But AFAICS the send/recv operation should *also*, after the signal has > been handled, fail and return an errno that describes the situation. What > libpq does is just check for a negative return value and read errno.
Yes, that's right. When ignoring the signal it's seems to work fine. > Shock horror update: it looks like the fix for the libpq bug I mentioned > did not make it into CVS somehow! Check pqReadData() and pqSendSome() > here: > > http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-misc.c?rev=1.130;content-type=text%2Fx-cvsweb-markup > > The default way of handling errors there, apart from a series of known > error codes, is still to issue an error message but leave the connection > in "CONNECTION_OK" state. Unless it's been handled elsewhere, that could > hide some types of connection error and possibly make libpqxx and libpq > itself go on trying for longer than necessary. > > See first discussion here (I can't find a followup discussion I do > remember taking place): > > http://www.nabble.com/libpq-and-connection-failures-tf123204.html#a339088 [...] >>> IIRC the bug was fixed in updates of all supported major versions around >>> the time 8.1 came out. >> I'm using postgresql 8.1 and libpqxx 2.6.8. I can discard this >> possibility? > > Now that I see that the fix is not in CVS as I thought, no. :-( =( >>> Three recommendations: set SIG_PIPE to SIG_IGN; ensure your libpq is up >>> to >>> date; and if you still have the slow timeouts after that, mess with your >>> networking stack (very carefully of course) to make it give up faster. >> So the keep-alive solution is discarded? I don't like to mess arround >> with the TCP general configuration because postgres is not the only >> service in the machine and I other services don't need so short timeouts. > > I could try to build some form of keepalive support, but I don't have much > time to work on it at the moment. There does seem to be some keepalive > mechanism in libpq; I guess that using it would also require help from the > application. One thing I don't understand. libpqxx tries to reestablish the connection because of the bug, and if that bug is fixed the keep-alive would not be necessary? -- Leandro Lucarella Integratech S.A. 4571-5252 _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
