Re: Deadlock detector fails to activate on a hot standby replica - Mailing list pgsql-hackers

From Vitaly Davydov
Subject Re: Deadlock detector fails to activate on a hot standby replica
Date
Msg-id b178ea8d-9ed9-48b3-b4f7-5cfc3ff6ee44@postgrespro.ru
Whole thread Raw
In response to Deadlock detector fails to activate on a hot standby replica  (Vitaly Davydov <v.davydov@postgrespro.ru>)
List pgsql-hackers
Dear Hackers,

I would like to propose a patch that fixes the problem, which has the roots in
the possibility of spontaneous SIGALRM signals when waiting for some timeouts.
The idea of the patch - ignore spontaneous SIGALRM signals and continue waiting
for expected timeouts or buffer unpinning by the conflicting backend. This
patch is not a final version. I plan to add a tap-test for this case.

I'm in doubt to put the calls of some page buffer specific functions into
ResolveRecoveryConflictWithBufferPin (standby.c), but otherwise we have to
do more changes in LockBufferForCleanup and ResolveRecoveryConflictWithBufferPin.

I also think, we have to add some description of the found problem in timeout.c,
because the implemented optimization of setitimer calls leads to some not
evident consequences. The optimization seems to be implemented in the commit:
09cf1d52267644cdbdb734294012cf1228745aaa

With best regards,
Vitaly
Attachment

pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Fix gistkillitems & add regression test to microvacuum
Next
From: Fujii Masao
Date:
Subject: Is abort() still needed in WalSndShutdown()?