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

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. 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