From: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | ashwinstar(at)gmail(dot)com |
Subject: | Changes to recovery_min_apply_delay are ignored while waiting for delay |
Date: | 2021-08-03 05:21:56 |
Message-ID: | CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I came across this issue while I was tweaking a TAP test with Ashwin for
this thread [1].
We noticed that while the startup process waits for a recovery delay, it does
not respect changes to the recovery_min_apply_delay GUC. So:
// Standby is waiting on recoveryWakeupLatch with a large
recovery_min_apply_delay value
node_standby->safe_psql('postgres', 'ALTER SYSTEM SET
recovery_min_apply_delay TO 0;');
node_standby->reload;
// Standby is still waiting, it does not proceed until the old timeout
is elapsed.
I attached a small patch to fix this. It makes it so that
recovery_min_apply_delay is reconsulted in the loop to redetermine the wait
interval. This makes it similar to the loop in CheckpointerMain, where
CheckPointTimeout is consulted after interrupts are handled:
if (elapsed_secs >= CheckPointTimeout)
continue; /* no sleep for us ... */
I have also added a test to 005_replay_delay.pl.
Regards,
Soumyadeep(VMware)
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Refresh-delayUntil-in-recovery-delay-loop.patch | text/x-patch | 5.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-08-03 05:28:38 | Re: Failed transaction statistics to measure the logical replication progress |
Previous Message | Richard Guo | 2021-08-03 04:03:29 | Sort keys are omitted incorrectly after grouping sets |