Re: We shouldn't signal process groups with SIGQUIT

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: We shouldn't signal process groups with SIGQUIT
Date: 2023-02-22 06:47:50
Message-ID: Y/W6lm197oBiQEDM@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> Just naively hacking this behaviour change into the current code, would yield
> sending SIGQUIT to postgres, and then SIGTERM to the whole process
> group. Which seems like a reasonable order? quickdie() should _exit()
> immediately in the signal handler, so we shouldn't get to processing the
> SIGTERM. Even if both signals are "reacted to" at the same time, possibly
> with SIGTERM being processed first, the SIGQUIT handler should be executed
> long before the next CFI().

I can see the sense in this argument and this order should work, still
adding more complication for the backends does not sound that
appealing to me.

What would be the advantage of doing that for groups other than
-StartupPID and -PgArchPID? These are the two groups of processes we
need to worry about, AFAIK.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-02-22 07:00:06 Re: Commitfest Manager
Previous Message Julien Rouhaud 2023-02-22 06:43:18 Re: pg_upgrade and logical replication