On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: > On Mon, Sep 14, 2020 at 3:53 PM Amit Langote <amitlangot...@gmail.com> wrote: > > On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera <alvhe...@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
