Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-04-09T21:00:41Z
Lists: pgsql-hackers 
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

Commits

  1. Fix recovery conflict SIGUSR1 handling.

  2. Redesign interrupt/cancel API for regex engine.

  3. Update contrib/trgm_regexp's memory management.

  4. Update tsearch regex memory management.

  5. Use MemoryContext API for regex memory management.