On Wed, Feb 10, 2021 at 8:19 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Tue, 9 Feb 2021 12:27:21 +0530, Bharath Rupireddy > <bharath.rupireddyforpostg...@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.
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. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com