On Tue, May 11, 2021 at 11:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, May 11, 2021 at 11:17 AM Amul Sul <sulamul@gmail.com> wrote:
> > I think I have much easier solution than this, will post that with update version patch set tomorrow.
>
> I don't know what you have in mind, but based on this discussion, it
> seems to me that we should just have 5 states instead of 4:
>
> 1. WAL is permitted.
> 2. WAL is being prohibited but some backends may not know about the change yet.
> 3. WAL is prohibited.
> 4. WAL is in the process of being permitted but XLogAcceptWrites() may
> not have been called yet.
> 5. WAL is in the process of being permitted and XLogAcceptWrites() has
> been called but some backends may not know about the change yet.
>
> If we're in state #3 and someone does pg_prohibit_wal(false) then we
> enter state #4. The checkpointer calls XLogAcceptWrites(), moves us to
> state #5, and pushes out a barrier. Then it waits for the barrier to
> be absorbed and, when it has been, it moves us to state #1. Then if
> someone does pg_prohibit_wal(true) we move to state #2. The
> checkpointer pushes out a barrier and waits for it to be absorbed.
> Then it calls XLogFlush() and afterward moves us to state #3.
>
> We can have any (reasonable) number of states that we want. There's
> nothing magical about 4.
Your idea makes sense, but IMHO, if we are first writing
XLogAcceptWrites() and then pushing out the barrier, then I don't
understand the meaning of having state #4. I mean whenever any
backend receives the barrier the system will always be in state #5.
So what do we want to do with state #4?
Is it just to make the state machine better? I mean in the checkpoint
process, we don't need separate "if checks" whether the
XLogAcceptWrites() is called or not, instead we can just rely on the
state, if it is #4 then we have to call XLogAcceptWrites(). If so
then I think it's okay to have an additional state, just wanted to
know what idea you had in mind?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com