| From: | feichanghong <feichanghong(at)qq(dot)com> |
|---|---|
| To: | feichanghong <feichanghong(at)qq(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, alvherre <alvherre(at)alvh(dot)no-ip(dot)org> |
| Subject: | Re:BUG #18371: There are wrong constraint residues when detach hash partiton concurrently |
| Date: | 2024-02-29 06:21:58 |
| Message-ID: | tencent_4DA59E77900C87CEBA0F0213000E64040D07@qq.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 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:
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.
> Based on the analysis above, should the added constraint for a hash partition
> 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.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0000-drop-constraint-for-hash-partition.patch | application/octet-stream | 5.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2024-02-29 07:08:19 | Re: BUG #18314: PARALLEL UNSAFE function does not prevent parallel index build |
| Previous Message | David G. Johnston | 2024-02-29 05:53:09 | Re: `order by random()` makes select-list `random()` invocations deterministic |