Is RecoveryConflictInterrupt() entirely safe in a signal handler?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Date: 2022-04-09 19:57:48
Message-ID: CA+hUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO=nEYKSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-04-09 20:38:25 Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Previous Message David G. Johnston 2022-04-09 19:38:49 Re: shared-memory based stats collector - v70