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

From Craig Ringer
Subject Re: [PATCH] ProcessInterrupts_hook
Date
Msg-id CAGRY4nxLAC2TekXmoWJgXXWTXdGDQtLx6OPuq3f4jTZ-YkwZqA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] ProcessInterrupts_hook  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] ProcessInterrupts_hook
List pgsql-hackers
On Sat, 20 Mar 2021 at 03:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 19, 2021 at 3:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not very comfortable about the idea of having the postmaster set
>> child processes' latches ... that doesn't sound terribly safe from the
>> standpoint of not allowing the postmaster to mess with shared memory
>> state that could cause it to block or crash.  If we already do that
>> elsewhere, then OK, but I don't think we do.

> It should be unnecessary anyway. We changed it a while back to make
> any SIGUSR1 set the latch ....

Hmm, so the postmaster could send SIGUSR1 without setting any particular
pmsignal reason?  Yeah, I suppose that could work.  Or we could recast
this as being a new pmsignal reason.

I'd be fine with either way.

I don't expect to be able to get to working on a concrete patch for this any time soon, so I'll be leaving it here unless someone else needs to pick it up for their extension work. The in-principle agreement is there for future work anyway.

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [PATCH] More docs on what to do and not do in extension code
Next
From: Noah Misch
Date:
Subject: Re: Dump public schema ownership & seclabels