Re: Is Recovery actually paused?
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: bharath.rupireddyforpostgres@gmail.com
Cc: dilipbalaut@gmail.com, nagata@sraoss.co.jp, sawada.mshk@gmail.com,
pgsql-hackers@lists.postgresql.org, robertmhaas@gmail.com,
simon@2ndquadrant.com
Date: 2021-02-10T02:49:52Z
Lists: pgsql-hackers
Attachments
- (unnamed) (text/plain)
At Tue, 9 Feb 2021 12:27:21 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in > What I meant was that if we were to add waiting logic inside > pg_wal_replay_pause, we should also have a timeout with some default > value, to avoid pg_wal_replay_pause waiting forever in the waiting > loop. Within that timeout, if the recovery isn't paused, > pg_wal_replay_pause will return probably a warning and a false(this > requires us to change the return value of the existing > pg_wal_replay_pause)? I thought that rm_redo finishes shortly unless any trouble happens. But on second thought, I found that I forgot a case of a recovery-conflict. So as you pointed out, pg_wal_replay_pause() needs a flag 'wait' to wait for a pause established. And the flag can be turned into "timeout". # And the prevous verision had another silly bug. > To avoid changing the existing API and return type, a new function > pg_get_wal_replay_pause_state is introduced. I mentioned about IN parameters, not OUTs. IN parameters can be optional to accept existing usage. pg_wal_replay_pause() is changed that way in the attached. If all of you still disagree with my proposal, I withdraw it. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
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