Is RecoveryConflictInterrupt() entirely safe in a signal handler?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Дата
Msg-id CA+hUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO=nEYKSg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: shared-memory based stats collector - v70
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors