On Thu, May 13, 2021 at 2:26 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, May 12, 2021 at 1:39 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > 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? > > Well, if you don't have that, how does the checkpointer know that it's > supposed to push out the barrier? > > You and Amul both seem to want to merge states #4 and #5. But how to > make that work? Basically what you are both saying is that, after we > move into the "going read-write" state, backends aren't immediately > told that they can write WAL, but have to keep checking back. But this > could be expensive. If you have one state that means that the > checkpointer has been requested to run XLogAcceptWrites() and push out > a barrier, and another state to mean that it has done so, then you > avoid that. Maybe that overhead wouldn't be large anyway, but it seems > like it's only necessary because you're trying to merge two states > which, from a logical point of view, are separate.
I don't have an objection to having 5 states, just wanted to understand your reasoning. So it makes sense to me. Thanks. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
