Re: Is Recovery actually paused?
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Yugo Nagata <nagata@sraoss.co.jp>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>
Date: 2021-02-10T15:08:57Z
Lists: pgsql-hackers
Attachments
- v13-0001-Provide-a-new-interface-to-get-the-recovery-paus.patch (text/x-patch) patch v13-0001
On Wed, Feb 10, 2021 at 10:02 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > I don't find any problem with this approach as well, but I personally > feel that the other approach where we don't wait in any API and just > return the recovery pause state is much simpler and more flexible. So > I will make the pending changes in that patch and let's see what are > the other opinion and based on that we can conclude. Thanks for the > patch. Here is an updated version of the patch which fixes the last two open problems 1. In RecoveryRequiresIntParameter set the recovery pause state in the loop so that if recovery resumed and pause requested again we can set to pause again. 2. If the recovery state is already 'paused' then don't set it back to the 'pause requested'. One more point is that in 'pg_wal_replay_pause' even if we don't change the state because it was already set to the 'paused' then also we call the WakeupRecovery. But I don't think there is any problem with that, if we think that this should be changed then we can make SetRecoveryPause return a bool such that if it doesn't do state change then it returns false and in that case we can avoid calling WakeupRecovery, but I felt that is unnecessary. Any other thoughts on this? -- 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