Re: [PATCH] ProcessInterrupts_hook - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] ProcessInterrupts_hook
Date
Msg-id 342709.1610988988@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] ProcessInterrupts_hook  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] ProcessInterrupts_hook  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 18, 2021 at 3:00 AM Craig Ringer
> <craig.ringer@enterprisedb.com> wrote:
>> A few times lately I've been doing things in extensions that've made me want to be able to run my own code whenever
InterruptPendingis true and CHECK_FOR_INTERRUPTS() calls ProcessInterrupts() 

> I've wanted this in the past, too, so +1 from me.

I dunno, this seems pretty scary and easily abusable.  There's not all
that much that can be done safely in ProcessInterrupts(), and we should
not be encouraging extensions to think they can add random processing
there.

>> What I really want to go along with this is a way for any backend to observe the postmaster's pmState and its
"Shutdown"variable's value, so any backend can tell if we're in FastShutdown, SmartShutdown, etc. 

> I've wanted something along this line, too, but what I was thinking
> about was more along the lines of having the postmaster signal the
> backends when a smart shutdown happened.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Add session statistics to pg_stat_database
Next
From: Bruce Momjian
Date:
Subject: Re: Key management with tests