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

On Tue, Jan 19, 2021 at 10:30 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Tue, 19 Jan 2021 11:41:18 +0900, Yugo NAGATA <nagata@sraoss.co.jp> wrote in
> > On Sun, 17 Jan 2021 11:33:52 +0530
> > Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > > > > >
> > > > > > > I think the current pg_is_wal_replay_paused() already has another purpose;
> > > > > > > this waits recovery to actually get paused. If we want to limit this API's
> > > > > > > purpose only to return the pause state, it seems better to fix this to return
> > > > > > > the actual state at the cost of lacking the backward compatibility. If we want
> > > > > > > to know whether pause is requested, we may add a new API like
> > > > > > > pg_is_wal_replay_paluse_requeseted(). Also, if we want to wait recovery to actually
> > > > > > > get paused, we may add an option to pg_wal_replay_pause() for this purpose.
> > > > > > >
> > > > > > > However, this might be a bikeshedding. If anyone don't care that
> > > > > > > pg_is_wal_replay_paused() can make user wait for a long time, I don't care either.
> > > > > >
> > > > > > I don't think that it will be blocked ever, because
> > > > > > pg_wal_replay_pause is sending the WakeupRecovery() which means the
> > > > > > recovery process will not be stuck on waiting for the WAL.
> > > >
> > > > Yes, there is no stuck on waiting for the WAL. However, it can be stuck during resolving
> > > > a recovery conflict. The process could wait for max_standby_streaming_delay or
> > > > max_standby_archive_delay at most before recovery get completely paused.
> > >
> > > Okay, I agree that it is possible so for handling this we have a
> > > couple of options
> > > 1. pg_is_wal_replay_paused(), interface will wait for recovery to
> > > actually get paused, but user have an option to cancel that.  So I
> > > agree that there is currently no option to just know that recovery
> > > pause is requested without waiting for its actually get paused if it
> > > is requested.  So one option is we can provide an another interface as
> > > you mentioned pg_is_wal_replay_paluse_requeseted(), which can just
> > > return the request status.  I am not sure how useful it is.
> >
> > If it is acceptable that pg_is_wal_replay_paused() makes users wait,
> > I'm ok for the current interface. I don't feel the need of
> > pg_is_wal_replay_paluse_requeseted().
>
> FWIW, the name "pg_is_wal_replay_paused" is suggesting "to know
> whether recovery is paused or not at present" and it would be
> surprising to see it to wait for the recovery actually paused by
> default.
>
> I think there's no functions to wait for some situation at least for
> now.  If we wanted to wait for some condition to make, we would loop
> over check-and-wait using plpgsql.
>
> If you desire to wait to replication to pause by a function, I would
> do that by adding a parameter to the function.
>
> pg_is_wal_replay_paused(OPTIONAL bool wait_for_pause)

This seems to be a fair point to me.  So I will add an option to the
API,  and if that is passed true then we will wait for recovery to get
paused.
otherwise, this will just return true if the pause is requested same
as the current behavior.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com