Re: [UNVERIFIED SENDER] Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()

From: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [UNVERIFIED SENDER] Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Date: 2021-09-07 08:32:06
Message-ID: 36ed78a0-5781-11d8-4842-afce849fb0c7@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 9/7/21 9:11 AM, Drouvot, Bertrand wrote:
>
> On 9/7/21 8:51 AM, Amit Kapila wrote:
>> On Tue, Sep 7, 2021 at 11:33 AM Drouvot, Bertrand
>> <bdrouvot(at)amazon(dot)com> wrote:
>>> Hi,
>>>
>>> On 9/7/21 7:58 AM, Dilip Kumar wrote:
>>>
>>>
>>> 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.
>>>
>>> Agree, if no objections, I'll prepare a patch with the modified
>>> approach of option 2) proposed by Amit (means passing the size from
>>> the outside in all the cases).
>>>
>> Sounds reasonable. Another point that needs some thought is do we want
>> to backpatch this change till v13?  I am not sure if there is any
>> user-visible bug here but maybe it is still good to fix this in back
>> branches. What do you think?
>
> Yes, +1 to backpatch till v13 "per precaution".
>
> I will first come back with a proposed version for master and once we
> agree on a final/polished version then I'll do the backpatch ones (if
> needed).

Please find enclosed patch v2 (for the master branch) implementing the
modified approach of option 2) proposed by Amit.

Thanks

Bertrand

Attachment Content-Type Size
v2-0001-ReorderBufferChangeMemoryUpdate-failed-assertion.patch text/plain 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-09-07 08:42:08 Re: .ready and .done files considered harmful
Previous Message Peter Eisentraut 2021-09-07 08:25:20 Re: Support tab completion for upper character inputs in psql