| From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> | 
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> | 
| 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:48:25 | 
| Message-ID: | 20210208174825.e3a3b4b3804548ea1e9f57b9@sraoss.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, 08 Feb 2021 17:32:46 +0900 (JST)
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> 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?
If a user call pg_wal_replay_pause while recovery is paused, users can
observe 'pause requested' during a sleep alghough the time window is short.  
It seems a bit odd that pg_wal_replay_pause changes the state like this
because This state meeans that recovery may not be 'paused'. 
-- 
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hou, Zhijie | 2021-02-08 09:13:08 | RE: Parallel INSERT (INTO ... SELECT ...) | 
| Previous Message | Justin Pryzby | 2021-02-08 08:46:45 | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM |