Re: Is Recovery actually paused?
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-20T12:29:39Z
Lists: pgsql-hackers
On Tue, Oct 20, 2020 at 3:00 PM Simon Riggs <simon@2ndquadrant.com> wrote: > > On Tue, 20 Oct 2020 at 09:50, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > Why would we want this? What problem are you trying to solve? > > > > > > The requirement is to know the last replayed WAL on the standby so > > > unless we can guarantee that the recovery is actually paused we can > > > never get the safe last_replay_lsn value. > > > > > > > If we do care, why not fix pg_is_wal_replay_paused() so it responds as you wish? > > > > > > Maybe we can also do that but pg_is_wal_replay_paused is an existing > > > API and the behavior is to know whether the recovery paused is > > > requested or not, So I am not sure is it a good idea to change the > > > behavior of the existing API? > > > > > > > Attached is the POC patch to show what I have in mind. > > If you don't like it, I doubt anyone else cares for the exact current > behavior either. Thanks for pointing those issues out. > > It would make sense to alter pg_wal_replay_pause() so that it blocks > until paused. > > I suggest you add the 3-value state as you suggest, but make > pg_is_wal_replay_paused() respond: > if paused, true > if requested, wait until paused, then return true > else false > > That then solves your issues with a smoother interface. > Make sense to me, I will change as per the suggestion. -- 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