RE: Partition Check not updated when insert into a partition

From: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Partition Check not updated when insert into a partition
Date: 2021-07-14 02:15:49
Message-ID: OS0PR01MB57161429E29F9870217B106C94139@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, July 13, 2021 2:52 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2021-Jun-23, houzj(dot)fnst(at)fujitsu(dot)com wrote:
>
> > For a multi-level partition, for example: table 'A' is partition of
> > table 'B', and 'B' is also partition of table 'C'. After I 'ALTER
> > TABLE C DETACH B', I thought partition constraint check of table 'C'
> > does not matter anymore if INSERT INTO table 'A'. But it looks like
> > the relcache of 'A' is not invalidated after detaching 'B'. And the
> > relcache::rd_partcheck still include the partition constraint of table
> > 'C'. Note If I invalidate the table 'A''s relcache manually, then next
> > time the relcache::rd_partcheck will be updated to the expected one which
> does not include partition constraint check of table 'C'.
>
> Hmm, if I understand correctly, this means that we need to invalidate relcache
> for all partitions of the partition being detached. Maybe like in the attached
> WIP ("XXX VERY CRUDE XXX DANGER EATS DATA") patch, which solves what
> you complained about, but I didn't run any other tests.
> (Also, in the concurrent case I think this should be done during the first
> transaction, so this patch is wrong for it.)
>
> Did you have a misbehaving test for the ATTACH case?

Thanks for the response.

Yes, I think the following example of ATTACH doesn't work as expected.

---------------------------------------------------------------
create table parttable1 (a int, b int, c int) partition by list(a);
create table parttable2 (a int, b int, c int) partition by list(b);
create table parttable3 (a int, b int, c int);
alter table parttable2 attach partition parttable3 for values in (1);

-----
----- INSERT a tuple into parttable3
----- Cache the partitioncheck in relcache::rd_partcheck
-----
insert into parttable3 values(1, 1, 0);

----- Attach a new top parent
alter table parttable1 attach partition parttable2 for values in (1);

-----
----- INSERT a tuple which doesn't satisfy the new top parent(parttable1)'s partitioncheck
----- But the INSERT will succeed which looks not as expected.
-----
insert into parttable3 values(999, 1, 0);

-----
----- And when I reconnect to clean the cache
----- INSERT a tuple which doesn't satisfy the new top parent(parttable1)'s partitioncheck
----- INSERT will fail due to partition check violation.
-----
insert into parttable3 values(999, 1, 0);

Best regards,
Hou zhijie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-07-14 02:17:55 Re: Introduce pg_receivewal gzip compression tests
Previous Message Ranier Vilela 2021-07-14 01:45:22 Re: Add proper planner support for ORDER BY / DISTINCT aggregates