Re: BUG #16153: foreign key update should probably move dependentrows in the case of tuple rerouting - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #16153: foreign key update should probably move dependentrows in the case of tuple rerouting
Date
Msg-id 20191212125229.GA8225@alvherre.pgsql
Whole thread Raw
In response to BUG #16153: foreign key update should probably move dependent rows in the case of tuple rerouting  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #16153: foreign key update should probably move dependent rows in the case of tuple rerouting  (Arne Roland <A.Roland@index.de>)
List pgsql-bugs
On 2019-Dec-05, PG Bug reporting form wrote:

> foreign key update should probably move dependent rows in the case of
> tuple rerouting
> instead of simply deleting them silently

Hmm.

> create table a (id serial, primary key (id)) partition by range (id);
> create table b (id serial,  primary key (id)) partition by range (id);
> alter table b add constraint a_fk foreign key (id) references a (id) on
> delete cascade;
> create table a1 partition of a for values from (1) to (2);
> create table a2 partition of a for values from (2) to (3);
> create table b1 partition of b for values from (1) to (2);
> create table b2 partition of b for values from (2) to (3);
> 
> insert into a (id) values (1);
> insert into b (id) values (1);
> 
> update a set id=2;
> 
> select * from b;

This seems to be a side-effect of how tuple updates work across
partitions.  My bet is that it's seen as just a deletion, which deletes
the referencing tuple because of the ON DELETE CASCADE; then the other
row is inserted and nothing else needs to happen.

You don't have ON UPDATE CASCADE in your example, so my expectation
would be that this should raise an error, per NO ACTION.  But if you
were to add ON UPDATE CASCADE, then yeah the referencing row should be
moved too somehow.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-bugs by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: BUG #16162: create index using gist_trgm_ops leads to panic
Next
From: Tom Lane
Date:
Subject: Re: BUG #16162: create index using gist_trgm_ops leads to panic