Horton

Re:BUG #18371: There are wrong constraint residues when detach hash partiton concurrently

feichanghong <feichanghong@qq.com>

View thread
From: feichanghong <feichanghong@qq.com>
To: feichanghong <feichanghong@qq.com>, pgsql-bugs <pgsql-bugs@lists.postgresql.org>, alvherre <alvherre@alvh.no-ip.org>
Date: 2024-02-29T06:21:58Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Stop creating constraints during DETACH CONCURRENTLY

  2. Rename SLRU elements in view pg_stat_slru

Attachments

&gt; This can work normally on range partitions. However, the constraint on hash
&gt; partitions uses satisfies_hash_partition with the OID of the parent table, and
&gt; the newly created constraint does not take effect. For example, in the following
&gt; case, although there is a t_p1_a_check constraint on t_p1, it is still possible
&gt; to perform an insert:
What I said here is wrong, the constraints on the hash partition will also take
effect. But this constraint depends on the oid of the parent partition.



&gt; Based on the analysis above, should the added constraint for a hash partition
&gt; be dropped after detachment?I have initially implemented this logic in the attached patch and added a
testcase. I really hope that developers can give me some suggestions.








Best Regards,
Fei Changhong
Alibaba Cloud Computing Ltd.


&nbsp;