Is RecoveryConflictInterrupt() entirely safe in a signal handler? - Mailing list pgsql-hackers

From Thomas Munro
Subject Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Date
Msg-id CA+hUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO=nEYKSg@mail.gmail.com
Whole thread Raw
Responses Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

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

(I noticed this incidentally while trying to follow along with the
nearby thread on 031_recovery_conflict.pl, but the question of why we
really need this of interest to me for a back-burner project I have to
try to remove all use of signals except for latches, and then remove
the signal emulation for Windows.  It may turn out to be a pipe dream,
but this stuff is one of the subproblems.)



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: shared-memory based stats collector - v70
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors