Re: Is Recovery actually paused?

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Is Recovery actually paused?
Date: 2020-10-22 14:20:49
Message-ID: CAFiTN-sGQZte5Oh8fLdzWcRkra+gU0v2EqZRs3mCifU+aDY+xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 22, 2020 at 6:59 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Wed, 21 Oct 2020 11:14:24 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> > On Wed, Oct 21, 2020 at 7:16 AM Dilip Kumar <dilipbalaut(at)gmail(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-10-22 14:25:48 Re: partition routing layering in nodeModifyTable.c
Previous Message Adam Brusselback 2020-10-22 14:07:29 Re: Implementing Incremental View Maintenance