Re: Is Recovery actually paused? - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Is Recovery actually paused?
Date
Msg-id CAFiTN-tBMpRVaTf55yNrb95y4odurDV39gOz8mg-QUqvH6ke5g@mail.gmail.com
Whole thread Raw
In response to Re: Is Recovery actually paused?  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Is Recovery actually paused?  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers


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 always returning true after pause requested.  Now, we will return whether pause requested or actually paused.  So for tool designer 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 will check other comments and respond along with the patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: How to expose session vs txn lock info in pg_locks view?
Next
From: Corey Huinker
Date:
Subject: Re: simplifying foreign key/RI checks