Re: [PATCH] Prevent hanging on unreachable hosts on startup

From: Ryan Kelly <rpkelly22(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [PATCH] Prevent hanging on unreachable hosts on startup
Date: 2012-08-28 11:40:07
Message-ID: 20120828114007.GA31047@llserver.lakeliving.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Aug 27, 2012 at 09:34:48PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Merlin Moncure 2012-08-28 15:06:20 Re: BUG #6489: Alter table with composite type/table
Previous Message Amit Kapila 2012-08-28 10:40:07 Re: Minor inheritance/check bug: Inconsistent behavior