>Deadlock bug was prevented by stop-gap measure in December commit.
>
>Full resolution patch attached for Startup process waits on buffer pins.
>
>Startup process sets SIGALRM when waiting on a buffer pin. If woken by
>alarm we send SIGUSR1 to all backends requesting that they check to see
>if they are blocking Startup process. If so, they throw ERROR/FATAL as
>for other conflict resolutions. Deadlock stop gap removed.
>max_standby_delay = -1 option removed to prevent deadlock.
>
>Reviews welcome, otherwise commit at end of week.
>
I think the patch has two problems.
* disable_standby_sig_alarm() does not clear standby_timeout_active flag when it succeeds in disabling the alarm.
* Assertion check in HoldingBufferPinThatDelaysRecovery() can fail with following scenario.
1. Two transactions, xact A and xact B, are running in a HotStandby server. 2. Xact A holds a pin on buffer X. 3.
Startupprocess calls LockBufferForCleanup() for buffer X, sets ProcGlobal->startupBufferPinWaitBufId = X, sends
PROCSIG_RECOVERY_CONFLICT_BUFFERPINsignal to both transactions, and sleeps. 4. Xact A handles the signal,
abortsitself, releases the pin on buffer X, and awake startup process. 5. Startup process wakes up and
setsProcGlobal->startupBufferPinWaitBufId = -1. 6. Xact B handles the signal, checks
ProcGlobal->startupBufferPinWaitBufId, and fails in the assertion check in HoldingBufferPinThatDelaysRecovery().
regards,
-- Hiroyuki YAMADA Kokolink Corporation yamada@kokolink.net
