Re: Remove incorrect assertion in reorderbuffer.c.

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(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 05:48:59
Message-ID: CAFiTN-sVnxGOwtXWkuYaB2JtfdHFV600HiVUOxOs=AQyXOiDxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2020-12-04 06:03:25 Re: Is it useful to record whether plans are generic or custom?
Previous Message Kyotaro Horiguchi 2020-12-04 05:48:22 Re: Huge memory consumption on partitioned table with FKs