From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | feichanghong(at)qq(dot)com |
Subject: | BUG #18371: There are wrong constraint residues when detach hash partiton concurrently |
Date: | 2024-02-28 11:30:46 |
Message-ID: | 18371-7fef49f63de13f02@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 18371
Logged by: Fei Changhong
Email address: feichanghong(at)qq(dot)com
PostgreSQL version: 16.2
Operating system: Operating system: centos 7,Kernel version: 5.10.13
Description:
Hi all,
When I tried to insert data into a table that had just been detached, I
encountered an error: "ERROR: could not open relation with OID 16384".
The environment information is as follows:
PostgreSQL branch: master.
commit: bcdfa5f2e2f274caeed20b2f986012a9cb6a259c
This issue can be reproduced with the following steps:
```
create table t(a int) partition by hash (a);
create table t_p1 partition of t for values with (modulus 2, remainder 0);
alter table t detach partition t_p1 concurrently ;
drop table t;
insert into t_p1 select 1;
```
When detaching a partition concurrently, the function
DetachAddConstraintIfNeeded
is called to convert the partition constraint of the detached partition into
a
regular constraint, and it is not dropped at the end of the detach
process.
This can work normally on range partitions. However, the constraint on
hash
partitions uses satisfies_hash_partition with the OID of the parent table,
and
the newly created constraint does not take effect. For example, in the
following
case, although there is a t_p1_a_check constraint on t_p1, it is still
possible
to perform an insert:
```
create table t(a int) partition by hash (a);
create table t_p1 partition of t for values with (modulus 2, remainder 0);
alter table t detach partition t_p1 concurrently ;
postgres=# \d+ t_p1
Table "public.t_p1"
Column | Type | Collation | Nullable | Default | Storage | Compression |
Stats target | Description
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
a | integer | | | | plain | |
|
Check constraints:
"t_p1_a_check" CHECK (satisfies_hash_partition('16384'::oid, 2, 0, a))
Access method: heap
postgres=# insert into t_p1 select 1;
INSERT 0 1
postgres=#
```
If the parent table has already been dropped, an error will occur during
constraint checking.
Based on the analysis above, should the added constraint for a hash
partition
be dropped after detachment?
From | Date | Subject | |
---|---|---|---|
Next Message | GADACHA Rachid (Acoss) | 2024-02-28 14:50:28 | [Bugg hash join and parallel worker] |
Previous Message | PG Bug reporting form | 2024-02-28 09:54:42 | BUG #18370: Issue accessing pgadmin4 web gui |