Re: Is Recovery actually paused?

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Subject: Re: Is Recovery actually paused?
Date: 2021-01-24 01:47:47
Message-ID: CAFiTN-tBMpRVaTf55yNrb95y4odurDV39gOz8mg-QUqvH6ke5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 23 Jan 2021 at 4:40 PM, Bharath Rupireddy <
bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:

> On Sat, Jan 23, 2021 at 1:36 PM Dilip Kumar <dilipbalaut(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2021-01-24 02:26:24 Re: simplifying foreign key/RI checks
Previous Message Andres Freund 2021-01-24 01:12:52 Re: How to expose session vs txn lock info in pg_locks view?