Re: Remove incorrect assertion in reorderbuffer.c.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove incorrect assertion in reorderbuffer.c.
Date: 2020-12-04 09:05:03
Message-ID: CAA4eK1KrY=1iMyfy1t4-MZWzf=TY-+fwPM-7JJHT5sZQc41PXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 4, 2020 at 11:19 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Thu, Dec 3, 2020 at 5:33 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > We start recording changes in ReorderBufferTXN even before we reach
> > SNAPBUILD_CONSISTENT state so that if the commit is encountered after
> > reaching that we should be able to send the changes of the entire
> > transaction. Now, while recording changes if the reorder buffer memory
> > has exceeded logical_decoding_work_mem then we can start streaming if
> > it is allowed and we haven't yet streamed that data. However, we must
> > not allow streaming to start unless the snapshot has reached
> > SNAPBUILD_CONSISTENT state.
> >
> > I have also improved the comments atop ReorderBufferResetTXN to
> > mention the case when we need to continue streaming after getting an
> > error.
> >
> > Attached patch for the above changes.
> >
> > Thoughts?
>
> LGTM.
>

Thanks for the review, Pushed!

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2020-12-04 09:06:10 Re: pg_stat_statements oddity with track = all
Previous Message Amit Kapila 2020-12-04 09:02:33 Re: Single transaction in the tablesync worker?