Re: Is Recovery actually paused?

At Tue, 9 Feb 2021 12:23:23 +0900, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote in
> On Tue, 09 Feb 2021 10:58:04 +0900 (JST)
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > I didn't asked about the internal logical correctness, but asked about
> > *actual harm* revealed to users. I don't see any actual harm in the
> > "wrong" transition because:
>
> Actually, the incorrect state transition is not so harmful except that
> users can observe unnecessary state changes. However, I don't think any
> actual harm in prohibit the incorrect state transition. So, I think we
> can do it.

I don't say that we cannot do that. Just it is needeless.

> > If we are going to introduce that complexity, I'd like to re-propose
> > to introduce interlocking between the recovery side and the
> > pause-requestor side instead of introducing the intermediate state,
> > which is the cause of the complexity.
> >
> > The attached PoC patch adds:
> >
> > - A solid checkpoint just before calling rm_redo. It doesn't add a
> > info_lck since the check is done in the existing lock section.
> >
> > - Interlocking between the above and SetRecoveryPause without adding a
> > shared variable.
> > (This is what I called "synchronous" before.)
>
> I think waiting in pg_wal_replay_pasue is a possible option, but this will
> also introduce other complexity to codes such as possibility of waiting for
> long or for ever. For example, waiting in SetRecoveryPause as in your POC
> patch appears to make recovery stuck in RecoveryRequiresIntParameter.

That is easily avoidable CFI in the loop.

> By the way, attaching other patch to a thread without the original patch
> will make commitfest and cfbot APP confused...

Oops! Sorry for that. I forgot to append .txt or such to the file name.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center