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: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [PATCH] Prevent hanging on unreachable hosts on startup
Date: 2012-01-05 14:23:55
Message-ID: 20120105142355.GB26760@llserver.lakeliving.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jan 04, 2012 at 09:36:57PM -0500, Tom Lane wrote:
> "Ryan P. Kelly" <rpkelly22(at)gmail(dot)com> writes:
> > The signal handler installed by setup_cancel_handler() will ignore
> > attempts to exit psql should a host be unreachable.
>
> Hm. That may be worth doing something about, but the proposed patch
> seems more like a quick-and-dirty hack than a solution. The main
> thing I don't like about it is that if we care about this scenario
> during initial startup, we should also care about it during a \c
> command, but just delaying the installation of the signal handler
> won't fix that case.
Sure, but do you still think moving the signal handler down is correct?
I've attached another patch that handles interrupting \c. I also noticed
there appears to be what looks like duplication of code in startup.c and
command.c in main() and do_connect() respectively. I'm wondering if I
they should be made to share the same code which (with my patch) would
then mean the signal handler could be left where it was.

> More generally, what if the server becomes unreachable mid-session?
> I'm not sure how much there is to be done about that case, since
> there's probably no good way to distinguish it from a query that
> takes a really long time. But if we're going to think about this,
> we might as well think about all the cases.
Well in this case we can still interrupt the query, no? This will drop
us back into the prompt, where we can safely \q.

>
> regards, tom lane

-Ryan Kelly

Attachment Content-Type Size
0001-Allow-interrupting-hanging-c-connection-attempts.patch text/x-diff 0 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Fetter 2012-01-05 16:53:40 Re: Proble Postgre SQL version 7.4.1
Previous Message Michael Meskes 2012-01-05 13:14:05 Re: BUG #6366: ECPG connection Memory Leak when using Host Variables