On Mon, Aug 27, 2012 at 09:34:48PM -0400, Tom Lane wrote:
> 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
The latest on this patch can be found here:
http://archives.postgresql.org/message-id/500151C4.5010509@enterprisedb.com
-Ryan Kelly