On Sun, Jan 24, 2021 at 7:17 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Sat, 23 Jan 2021 at 4:40 PM, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
>>
>> On Sat, Jan 23, 2021 at 1:36 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>> > Please find the patch for the same. I haven't added a test case for
>> > this yet. I mean we can write a test case to pause the recovery and
>> > get the status. But I am not sure that we can really write a reliable
>> > test case for 'pause requested' and 'paused'.
>>
>> +1 to just show the recovery pause state in the output of
>> pg_is_wal_replay_paused. But, should the function name
>> "pg_is_wal_replay_paused" be something like
>> "pg_get_wal_replay_pause_state" or some other? To me, when "is" exists
>> in a function, I expect a boolean output. Others may have better
>> thoughts.
>>
>> IIUC the above change, ensuring the recovery is paused after it's
>> requested lies with the user. IMHO, the main problem we are trying to
>> solve is not met
>
>
> Basically earlier their was no way for the user yo know whether the recovery is actually paused or not because it was
alwaysreturning true after pause requested. Now, we will return whether pause requested or actually paused. So > for
tooldesigner who want to wait for recovery to get paused can have a loop and wait until the recovery state reaches to
paused. That will give a better control.
I get it and I agree to have that change. My point was whether we can
have a new function pg_wal_replay_pause_and_wait that waits until
recovery is actually paused ((along with pg_is_wal_replay_paused
returning the actual state than a true/false) so that tool developers
don't need to have the waiting code outside, if at all they care about
it? Others may have better thoughts than me.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com