Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate() - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Date
Msg-id CAFiTN-smGWa8zYVsQVm7qRdXsr7JD8sokcKdfBhyF1onRORGdw@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
List pgsql-hackers
On Tue, Sep 7, 2021 at 11:10 AM Amit Kapila <amit.kapila16@gmail.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

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Column Filtering in Logical Replication
Next
From: Alexander Lakhin
Date:
Subject: Re: stat() vs ERROR_DELETE_PENDING, round N + 1