On Thu, Oct 22, 2020 at 7:50 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, Oct 22, 2020 at 6:59 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > At Wed, 21 Oct 2020 11:14:24 -0400, Robert Haas <robertmhaas@gmail.com> wrote in
> > > On Wed, Oct 21, 2020 at 7:16 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > > One idea could be, if the recovery process is waiting for WAL and a
> > > > recovery pause is requested then we can assume that the recovery is
> > > > paused because before processing the next wal it will always check
> > > > whether the recovery pause is requested or not.
> > ..
> > > However, it might be better to implement this by having the system
> > > absorb the pause immediately when it's in this state, rather than
> > > trying to detect this state and treat it specially.
> >
> > The paused state is shown in pg_stat_activity.wait_event and it is
> > strange that pg_is_wal_replay_paused() is inconsistent with the
> > column.
>
> Right
>
> To make them consistent, we need to call recoveryPausesHere()
> > at the end of WaitForWALToBecomeAvailable() and let
> > pg_wal_replay_pause() call WakeupRecovery().
> >
> > I think we don't need a separate function to find the state.
>
> The idea makes sense to me. I will try to change the patch as per the
> suggestion.
Here is the patch based on this idea.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com