From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate() |
Date: | 2021-09-07 05:58:24 |
Message-ID: | CAFiTN-smGWa8zYVsQVm7qRdXsr7JD8sokcKdfBhyF1onRORGdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 7, 2021 at 11:10 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Isn't it better if we use option 2) at all places as then we won't
> >> need any special check inside ReorderBufferChangeMemoryUpdate()?
> >
> >
> > If we want to do this then be careful about
> REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID change. Basically,
> ReorderBufferChangeMemoryUpdate() ignores this type of change whereas
> ReorderBufferChangeSize(), consider at least sizeof(ReorderBufferChange)
> bytes to this change. So if we compute the size using
> ReorderBufferChangeSize() outside of ReorderBufferChangeMemoryUpdate(),
> then total size will be different from what we have now. Logically, we
> should be ignoring/asserting REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID in
> ReorderBufferChangeSize(), because ReorderBufferChangeMemoryUpdate() is the
> only caller for this function.
> >
>
> Why can't we simply ignore it in ReorderBufferChangeMemoryUpdate() as
> we are doing now?
>
Yeah right, we can actually do that, it doesn't matter even if we are
passing the size from outside.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-09-07 05:59:58 | Re: strange case of "if ((a & b))" |
Previous Message | Dilip Kumar | 2021-09-07 05:56:17 | Re: Column Filtering in Logical Replication |