Re: problem with RETURNING and update row movement

On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Mon, Sep 14, 2020 at 3:53 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > 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.
>
> I agree on that point.
>
> > 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.
>
> IIUC, I think two issues are discussed in the thread [1]: (a) there is
> currently no way to define the set of meaningful system columns for a
> partitioned table that contains pluggable storages other than standard
> heap, and (b) even in the case where the set is defined as before,
> like partitioned tables that don’t contain any pluggable storages,
> system column values are not obtained from a tuple inserted into a
> partitioned table in cases as reported in [1], because virtual slots
> are assigned for partitioned tables [2][3].  (I think the latter is
> the original issue in the thread, though.)

Right, (b) can be solved by using a leaf partition's tuple slot as
proposed.  Although (a) needs a long term fix.

> I think we could fix this update-tuple-routing-vs-RETURNING issue
> without the fix for (a).  But to transfer system column values in a
> cleaner way, I think we need to fix (b) first so that we can always
> obtain/copy them from the new tuple moved to another partition by
> INSERT following DELETE.

Yes, I think you are right.  Although, I am still not sure how to
"copy" system columns from one partition's slot to another's, that is,
without assuming what they are.

> (I think we could address this issue for v11 independently of [1], off course.)

Yeah.

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