On Mon, Sep 14, 2020 at 10:45 PM Amit Langote <amitlangot...@gmail.com> wrote: > On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita <etsuro.fuj...@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
v5-0001-Fix-a-bug-with-RETURNING-when-UPDATE-moves-tuple-HEAD.patch
Description: Binary data
v5-0001-Fix-a-bug-with-RETURNING-when-UPDATE-moves-tuple-PG11.patch
Description: Binary data
