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

From Kyotaro Horiguchi
Subject Re: Is Recovery actually paused?
Date
Msg-id 20210119.140010.1037648043487816682.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Is Recovery actually paused?  (Yugo NAGATA <nagata@sraoss.co.jp>)
Responses Re: Is Recovery actually paused?  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
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)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: POC: postgres_fdw insert batching
Next
From: Greg Nancarrow
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)