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.)
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.
(I think we could address this issue for v11 independently of [1], off course.)
Best regards,
Etsuro Fujita
[1] https://www.postgresql.org/message-id/141051591267657%40mail.yandex.ru
[2] https://www.postgresql.org/message-id/CA%2BHiwqHrsNa4e0MfpSzv7xOM94TvX%3DR0MskYxYWfy0kjL0DAdQ%40mail.gmail.com
[3] https://www.postgresql.org/message-id/20200811180231.fcssvhelqpnydnx7%40alap3.anarazel.de
