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

From Etsuro Fujita
Subject Re: problem with RETURNING and update row movement
Date
Msg-id CAPmGK16CZy1ymHOWLGhnPM4MA3YEHE8UU-a15bV92SCc+STAqQ@mail.gmail.com
Whole thread Raw
In response to Re: problem with RETURNING and update row movement  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: problem with RETURNING and update row movement  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Mon, Sep 14, 2020 at 10:45 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > 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.

You mean what is proposed in [3]?

> > 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 just thought we assume that partitions support all the existing
system attributes until we have the fix for (a), i.e., the slot
assigned for a partition must have the getsysattr callback routine
from which we can fetch each existing system attribute of a underlying
tuple in the slot, regardless of whether that system attribute is used
for the partition or not.

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

I noticed that I modified your patch incorrectly.  Sorry for that.
Attached is an updated patch fixing that.  I also added a bit of code
to copy CTID from the new tuple moved to another partition, not just
table OID, and did some code/comment adjustments, mainly to match
other places.  I also created a patch for PG11, which I am attaching
as well.

Best regards,
Etsuro Fujita

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Next
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting