Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash
Date: 2009-12-09 14:28:47
Message-ID: 1274.1260368927@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Yeah, on reflection, calling elog in the SIGQUIT handler is just waiting
> for trouble. The call could block for any number of reasons, because
> there is a boatload of functionality that comes with a logging call. In
> the overall scheme of things, you don't really lose much if you just
> delete the call altogether, because in the event that it's called the
> postmaster will already have logged that it is going to kill all
> children. Or there ought to be some kind of alarm that would abort the
> thing if it takes too long.

Well, the point of that call is not to log the event. The point is to
tell the client why it's losing its connection. Admittedly there are
assorted corner cases where that would fail, but it works well enough
often enough that I don't want to just delete the attempt.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Peter Koczan 2009-12-09 17:25:13 ident authentication over tcp
Previous Message Bradley Kieser 2009-12-09 14:08:02 Re: Cannot increase connection limit?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-09 14:39:45 Re: XLogInsert
Previous Message Zdenek Kotala 2009-12-09 14:18:58 Re: [patch] pg_ctl init extension