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. -- Robert Haas EDB: http://www.enterprisedb.com
