On Thu, May 13, 2021 at 2:26 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, May 12, 2021 at 1:39 AM Dilip Kumar <dilipbalaut@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