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 |
Thread: | |
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 — https://www.EnterpriseDB.com/
"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 |
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 |