From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | nagata(at)sraoss(dot)co(dot)jp |
Cc: | dilipbalaut(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, simon(at)2ndquadrant(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is Recovery actually paused? |
Date: | 2021-01-19 05:00:10 |
Message-ID: | 20210119.140010.1037648043487816682.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 19 Jan 2021 11:41:18 +0900, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote in
> On Sun, 17 Jan 2021 11:33:52 +0530
> Dilip Kumar <dilipbalaut(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-01-19 05:02:16 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Amit Langote | 2021-01-19 04:51:53 | Re: POC: postgres_fdw insert batching |