Bruce Momjian <bruce@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
