Re: Parallel worker hangs while handling errors. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel worker hangs while handling errors.
Date
Msg-id 2764320.1596823234@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel worker hangs while handling errors.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel worker hangs while handling errors.  (Robert Haas <robertmhaas@gmail.com>)
Re: Parallel worker hangs while handling errors.  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Aug 7, 2020 at 12:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That SETMASK call will certainly unblock SIGQUIT, so I don't see what
>> your point is.

> I can't figure out if you're trolling me here or what. It's true that
> the PG_SETMASK() call will certainly unblock SIGQUIT, but that would
> also be true if the sigdelset() call were absent.

The point of the sigdelset is that if somewhere later on, we install
the BlockSig mask, then SIGQUIT will remain unblocked.  You asserted
upthread that noplace in these processes ever does so; maybe that's
true today, or maybe not, but the intent of this code is that *once
we get through initialization* SIGQUIT will remain unblocked.

I'll concede that it's not 100% clear whether or not these processes
need to re-block SIGQUIT during error recovery.  I repeat, though,
that I'm disinclined to change that without some evidence that there's
actually a problem with the way it works now.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Trukhanov
Date:
Subject: Re: Improve handling of pg_stat_statements handling of bind "IN" variables
Next
From: Robert Haas
Date:
Subject: Re: PROC_IN_ANALYZE stillborn 13 years ago