>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. Startup process calls LockBufferForCleanup() for buffer X,
sets ProcGlobal->startupBufferPinWaitBufId = X,
sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN signal to both transactions,
and sleeps.
4. Xact A handles the signal,
aborts itself,
releases the pin on buffer X,
and awake startup process.
5. Startup process wakes up
and sets ProcGlobal->startupBufferPinWaitBufId = -1.
6. Xact B handles the signal,
checks ProcGlobal->startupBufferPinWaitBufId,
and fails in the assertion check in HoldingBufferPinThatDelaysRecovery().
regards,
--
Hiroyuki YAMADA
Kokolink Corporation
yam...@kokolink.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
