Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Дата
Msg-id CAA4eK1L9JbhsHZpeaFrAMc7ZrPUHqd6AAERxqwZQ5n9J4=X1-g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Ответы Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Список pgsql-hackers
On Tue, Sep 7, 2021 at 11:33 AM Drouvot, Bertrand <bdrouvot@amazon.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.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/assertingREORDER_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
thesize 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?

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Column Filtering in Logical Replication
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: stat() vs ERROR_DELETE_PENDING, round N + 1