Re: problem with RETURNING and update row movement

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problem with RETURNING and update row movement
Date: 2020-09-14 06:53:24
Message-ID: CA+HiwqEneM_iKye3_a68PiG6V524oTgyPXZBwV3X34mRRzZ0-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro,

On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2020-09-14 07:51:54 Re: A micro-optimisation for walkdir()
Previous Message David Rowley 2020-09-14 05:27:00 Re: Optimising compactify_tuples()