Re: [PATCH] ProcessInterrupts_hook

From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
Subject: Re: [PATCH] ProcessInterrupts_hook
Date: 2021-01-19 06:42:31
Message-ID: CAGRY4nyNfscmQiZBCNT7cBYnQxJLAAVCGz+GZAQDAco1Fbb01w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 19 Jan 2021 at 12:44, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
wrote:

>
> > We're about halfway there already, see 7e784d1dc. I didn't do the
>> > other half because it wasn't necessary to the problem, but exposing
>> > the shutdown state more fully seems reasonable.
>>
>
> Excellent, I'll take a look. Thanks.
>

That looks very handy already.

Extending it to be set before SIGTERM too would be handy.

My suggestion, which I'm happy to post in patch form if you think it's
reasonable:

* Change QuitSignalReason to ExitSignalReason to cover both SIGTERM (fast)
and SIGQUIT (immediate)

* Rename PMQUIT_FOR_STOP to PMEXIT_IMMEDIATE_SHUTDOWN

* Add enumeration values PMEXIT_SMART_SHUTDOWN and PMEXIT_FAST_SHUTDOWN

* For a fast shutdown, in pmdie()'s SIGINT case call
SetExitSignalReason(PMEXIT_FAST_SHUTDOWN), so that when
PostmasterStateMachine() calls SignalSomeChildren(SIGTERM, ...) in response
to PM_STOP_BACKENDS, the reason is already available.

* For smart shutdown, in pmdie()'s SIGTERM case call
SetExitSignalReason(PMEXIT_SMART_SHUTDOWN) and set the latch of every live
backend. There isn't any appropriate PROCSIG so unless we want to overload
PROCSIG_WALSND_INIT_STOPPING (ick), but I think it'd generally be
sufficient to check GetExitSignalReason() in backend main loops.

The fast shutdown case seems like a no-brainer extension of your existing
patch.

I'm not entirely sure about the smart shutdown case. I don't want to add a
ProcSignal slot just for this and the info isn't urgent anyway. I think
that by checking for postmaster shutdown in the backend main loop we'd be
able to support eager termination of idle backends on smart shutdown
(immediately, or after an idle grace period), which is something I've
wanted for quite some time. It shouldn't be significantly expensive
especially in the idle loop.

Thoughts?

(Also I want a hook in PostgresMain's idle loop for things like this).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2021-01-19 06:46:28 Re: simplifying foreign key/RI checks
Previous Message Dilip Kumar 2021-01-19 06:42:14 Re: Is Recovery actually paused?