Re: a misbehavior of partition row movement (?) - Mailing list pgsql-hackers

From Amit Langote
Subject Re: a misbehavior of partition row movement (?)
Date
Msg-id CA+HiwqH2gWBDUotwtnY7qnp+K5j0J4tzUDycqcePA7Yy1s4MbQ@mail.gmail.com
Whole thread Raw
In response to Re: a misbehavior of partition row movement (?)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: a misbehavior of partition row movement (?)
Re: a misbehavior of partition row movement (?)
Re: a misbehavior of partition row movement (?)
List pgsql-hackers
On Tue, Jan 11, 2022 at 8:23 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2022-Jan-11, Amit Langote wrote:
> > As for the fix to make cross-partition updates work correctly with
> > foreign keys, I just realized it won't work for the users' existing
> > foreign keys, because the parent table's triggers that are needed for
> > the fix to work would not be present.  Were you thinking that we'd ask
> > users of v13 and v14 to drop and recreate those constraints?
>
> Yeah, more or less.  Also, any tables created from 13.6 onwards.
>
> I was mainly thinking that we'll still have people creating new clusters
> using pg13 for half a decade.

Okay, I created versions of the patch series for branches 13 and 14
(.txt files).  The one for HEAD is also re-attached.

Note that the fix involves adding fields to ResultRelInfo -- v13 needs
2 additional, while v14 and HEAD need 1.  That combined with needing
new catalog entries for parent FK triggers, back-patching this does
make me a bit uncomfortable.  Another thing to consider is that we
haven't seen many reports of the problem (UPDATEs of partitioned PK
tables causing DELETEs in referencing tables), even though it can be
possibly very surprising to those who do run into it.

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

Attachment

pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: TAP test to cover "EndOfLogTLI != replayTLI" case
Next
From: Amit Langote
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions