Re: problem with RETURNING and update row movement - Mailing list pgsql-hackers

From Amit Langote
Subject Re: problem with RETURNING and update row movement
Date
Msg-id CA+HiwqEneM_iKye3_a68PiG6V524oTgyPXZBwV3X34mRRzZ0-w@mail.gmail.com
Whole thread Raw
In response to Re: problem with RETURNING and update row movement  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: problem with RETURNING and update row movement
List 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 by date:

Previous
From: David Rowley
Date:
Subject: Re: Optimising compactify_tuples()
Next
From: Juan José Santamaría Flecha
Date:
Subject: Re: A micro-optimisation for walkdir()