Re: An example of bugs for Hot Standby

>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