|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||vignesh C <vignesh21(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Parallel worker hangs while handling errors.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Sep 11, 2020 at 4:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's not clear to me whether we want to institute the "accepting SIGQUIT
>> is always okay" rule in processes that didn't already have code to change
> I think a backend process that isn't timely handling SIGQUIT is by
> that very fact buggy. "pg_ctl stop -mi" isn't a friendly suggestion.
> So I favor trying to make it uniform.
Well, if we want to take a hard line about that, we should centralize
the setup of SIGQUIT. The attached makes InitPostmasterChild do it,
and removes the duplicative code from elsewhere.
I also flipped autovacuum and walsender from using quickdie to using
SignalHandlerForCrashExit. Whatever you think about the safety or
unsafety of quickdie, there seems no reason for autovacuum to be trying
to tell its nonexistent client about a shutdown. I don't think it's
terribly useful for a walsender either, though maybe somebody has a
different opinion about that?
regards, tom lane
|Next Message||Peter Eisentraut||2020-09-12 18:37:52||Re: Missing "Up" navigation link between parts and doc root?|
|Previous Message||Tomas Vondra||2020-09-12 16:13:03||Re: WIP: BRIN multi-range indexes|