On Mon, Aug 27, 2012 at 09:34:48PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Tom, can you comment on this patch because you commented on the previous > > version? Thanks. > > Doesn't that provoke a pile of compiler warnings about local variables > potentially being altered during longjmp? It sure looks pretty unsafe > from here. It also fails to print any error message if a connection > attempt is canceled. > > A bigger-picture question is just how safe it is to longjmp out of libpq > partway through a connection attempt. At the very least, that's likely > to leak an open socket and some memory. Maybe that doesn't matter too > much for psql, but I'm not convinced. It seems fairly likely that > internal state for libc (malloc), openssl, etc, could be left in a > corrupt state if the interrupt happens at just the wrong time. (This > didn't matter so much for the original proposal, where we'd just have > been exiting psql anyway on failure. But if it's in \c then we want > psql to still be operational after a failure.) > > We could perhaps dodge the longjmp safety question by using a > PQconnectStartParams/PQconnectPoll loop. I'm not sure that provides > 100% the same functionality --- in particular, I think it wouldn't allow > interrupting out of a DNS name resolution delay. But it'd be less > likely to result in strange crashes. > > regards, tom lane
The latest on this patch can be found here: http://archives.postgresql.org/message-id/500151c4.5010...@enterprisedb.com -Ryan Kelly -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
