Re: Partition Check not updated when insert into a partition

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
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-12 18:51:37
Message-ID: 202107121851.gdf3cqv4v26g@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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?

Álvaro Herrera 39°49'30"S 73°17'W —
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)

Attachment Content-Type Size
inval-partitions.patch text/x-diff 741 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-07-12 19:39:42 Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Previous Message Peter Eisentraut 2021-07-12 18:50:23 Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values