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

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

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2012-08-28 02:40:53 Re: BUG #6489: Alter table with composite type/table
Previous Message Tom Lane 2012-08-27 20:34:01 Re: Minor inheritance/check bug: Inconsistent behavior