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

Thomas Munro <thomas.munro@gmail.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.  Which, of course,
demonstrates the folly of allowing signal handlers to call much of
anything; but especially doing so without clearly marking the called
functions as needing to be signal safe.

            regards, tom lane