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