Re: Is Recovery actually paused?
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-22T15:06:48Z
Lists: pgsql-hackers
Attachments
- v1-0001-pg_is_wal_replay_paused-will-wait-for-recovery-to.patch (text/x-patch) patch v1-0001
On Thu, Oct 22, 2020 at 7:50 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, Oct 22, 2020 at 6:59 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > > > At Wed, 21 Oct 2020 11:14:24 -0400, Robert Haas <robertmhaas@gmail.com> wrote in > > > On Wed, Oct 21, 2020 at 7:16 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > One idea could be, if the recovery process is waiting for WAL and a > > > > recovery pause is requested then we can assume that the recovery is > > > > paused because before processing the next wal it will always check > > > > whether the recovery pause is requested or not. > > .. > > > However, it might be better to implement this by having the system > > > absorb the pause immediately when it's in this state, rather than > > > trying to detect this state and treat it specially. > > > > The paused state is shown in pg_stat_activity.wait_event and it is > > strange that pg_is_wal_replay_paused() is inconsistent with the > > column. > > Right > > To make them consistent, we need to call recoveryPausesHere() > > at the end of WaitForWALToBecomeAvailable() and let > > pg_wal_replay_pause() call WakeupRecovery(). > > > > I think we don't need a separate function to find the state. > > The idea makes sense to me. I will try to change the patch as per the > suggestion. Here is the patch based on this idea. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Be clear about whether a recovery pause has taken effect.
- 32fd2b57d7f6 14.0 landed
-
Pause recovery for insufficient parameter settings
- 15251c0a60be 14.0 cited
-
Remove most volatile qualifiers from xlog.c
- 6ba4ecbf477e 9.5.0 cited