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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs