Re: problem with RETURNING and update row movement

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: problem with RETURNING and update row movement
Дата
Msg-id CA+HiwqEneM_iKye3_a68PiG6V524oTgyPXZBwV3X34mRRzZ0-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: problem with RETURNING and update row movement  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: problem with RETURNING and update row movement  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Список pgsql-hackers
Hi Alvaro,

On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> I noticed that this bugfix has stalled, probably because the other
> bugfix has also stalled.
>
> It seems that cleanly returning system columns from table AM is not
> going to be a simple task -- whatever fix we get for that is likely not
> going to make it all the way to PG 12.  So I suggest that we should fix
> this bug in 11-13 without depending on that.

Although I would be reversing course on what I said upthread, I tend
to agree with that, because the core idea behind the fix for this
issue does not seem likely to be invalidated by any conclusion
regarding the other issue.  That is, as far as the issue here is
concerned, we can't avoid falling back to using the source partition's
RETURNING projection whose scan tuple is provided using the source
partition's tuple slot.

However, given that we have to pass the *new* tuple to the projection,
not the old one, we will need a "clean" way to transfer its (the new
tuple's) system columns into the source partition's tuple slot.  The
sketch I gave upthread of what that could look like was not liked by
Fujita-san much.



--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Optimising compactify_tuples()
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: A micro-optimisation for walkdir()