Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

Hi,

On 2022-04-09 14:39:16 -0700, Andres Freund wrote:
> On 2022-04-09 17:00:41 -0400, Tom Lane wrote:
> > Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > > Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
> > > doesn't just set a sig_atomic_t flag and poke the latch. Is the extra
> > > stuff it does safe? For example, is this call stack OK (to pick one
> > > that jumps out, but not the only one)?
> >
> > > procsignal_sigusr1_handler
> > > -> RecoveryConflictInterrupt
> > > -> HoldingBufferPinThatDelaysRecovery
> > > -> GetPrivateRefCount
> > > -> GetPrivateRefCountEntry
> > > -> hash_search(...hash table that might be in the middle of an update...)
> >
> > Ugh. That one was safe before somebody decided we needed a hash table
> > for buffer refcounts, but it's surely not safe now.
>
> Mea culpa. This is 4b4b680c3d6d - from 2014.

Whoa. There's way worse: StandbyTimeoutHandler() calls
SendRecoveryConflictWithBufferPin(), which calls CancelDBBackends(), which
acquires lwlocks etc.

Which very plausibly is the cause for the issue I'm investigating in
https://www.postgresql.org/message-id/20220409220054.fqn5arvbeesmxdg5%40alap3.anarazel.de

Greetings,

Andres Freund