Re: Is Recovery actually paused?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: nagata(at)sraoss(dot)co(dot)jp
Cc: dilipbalaut(at)gmail(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, robertmhaas(at)gmail(dot)com, simon(at)2ndquadrant(dot)com
Subject: Re: Is Recovery actually paused?
Date: 2021-02-08 08:32:46
Message-ID: 20210208.173246.1280008175961471074.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 8 Feb 2021 14:12:35 +0900, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote in
> > > > I think the right fix should be that the state should never go from
> > > > ‘paused’ to ‘pause requested’ so I think pg_wal_replay_pause should take
> > > > care of that.
> > >
> > > It makes sense to take care of this in pg_wal_replay_pause, but I wonder
> > > it can not handle the case that a user resume and pause again while a sleep.
> >
> > Right, we will have to check and set in the loop. But we should not
> > allow the state to go from paused to pause requested irrespective of
> > this.
>
> I agree with you.

Is there any actual harm if PAUSED returns to REQUESETED, assuming we
immediately change the state to PAUSE always we see REQUESTED in the
waiting loop, despite that we allow change the state from PAUSE to
REQUESTED via NOT_PAUSED between two successive loop condition checks?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Wang, Shenhao 2021-02-08 08:34:47 RE: parse mistake in ecpg connect string
Previous Message Markus Wanner 2021-02-08 08:31:12 repeated decoding of prepared transactions