| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | feichanghong <feichanghong(at)qq(dot)com> |
| Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #18371: There are wrong constraint residues when detach hash partiton concurrently |
| Date: | 2025-10-11 18:35:36 |
| Message-ID: | 202510111834.yxmra6mxo5zp@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2024-Jul-15, alvherre wrote:
> We should definitely not have this constraint on hash-partition tables
> after the detach. However, I wonder if instead of adding it and later
> removing it as you propose, it wouldn't be better to just not add it in
> the first place. As a first step, I tried commenting out and found that
> no interesting test fails (only alter_table.sql fails but only because
> the constraint is not there when looking for it specifically.)
Pushed a fix for this per report in
https://postgr.es/m/19070-781326347ade7c57@postgresql.org
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-10-12 08:10:13 | Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade |
| Previous Message | Álvaro Herrera | 2025-10-11 18:34:18 | Re: Re: BUG #19070: issue with DETACH PARTITION CONCURRENTLY on a hash partition table |