At Tue, 9 Feb 2021 12:23:23 +0900, Yugo NAGATA <nag...@sraoss.co.jp> wrote in > On Tue, 09 Feb 2021 10:58:04 +0900 (JST) > Kyotaro Horiguchi <horikyota....@gmail.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
