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

Álvaro Herrera <alvherre@kurilemu.de>

From: Álvaro Herrera <alvherre@kurilemu.de>

To: feichanghong <feichanghong@qq.com>

Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>

Date: 2025-10-11T18:35:36Z

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 →

Stop creating constraints during DETACH CONCURRENTLY
- ea06f97eeb33 17.7 landed
- bdae98495660 15.15 landed
- b835759ec7e8 16.11 landed
- b753be38a4a2 14.20 landed
- 3231fd045522 19 (unreleased) landed
- 08c037dff961 18.1 landed
Rename SLRU elements in view pg_stat_slru
- bcdfa5f2e2f2 17.0 cited

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.