On Tue, May 11, 2021 at 11:54 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, May 11, 2021 at 11:17 AM Amul Sul <sula...@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
