From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel worker hangs while handling errors. |
Date: | 2020-08-07 18:15:35 |
Message-ID: | CA+TgmobB7Xyh8E1Uy3xWyyuys_oUGajJz7Xbu3sp0hzDz0EFcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 7, 2020 at 2:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The point of the sigdelset is that if somewhere later on, we install
> the BlockSig mask, then SIGQUIT will remain unblocked.
I mean, we're just repeating the same points here, but that's not what
the comment says.
> You asserted
> upthread that noplace in these processes ever does so; maybe that's
> true today, or maybe not,
It's easily checked using 'git grep'.
> but the intent of this code is that *once
> we get through initialization* SIGQUIT will remain unblocked.
I can't speak to the intent, but I can speak to what the comment says.
> I'll concede that it's not 100% clear whether or not these processes
> need to re-block SIGQUIT during error recovery.
I think it's entirely clear that they do not, and I have explained my
reasoning already.
> 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.
I've also already explained why I don't agree with this perspective.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-07 18:41:41 | Re: PROC_IN_ANALYZE stillborn 13 years ago |
Previous Message | Robert Haas | 2020-08-07 18:03:37 | Re: PROC_IN_ANALYZE stillborn 13 years ago |