From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert |
Date: | 2024-06-29 00:15:09 |
Message-ID: | Zn9SDY0r9fLTqqDO@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Jun 28, 2024 at 01:27:17PM +0200, Alvaro Herrera wrote:
> I guess you could also fix this by adding a PK constraint to the parent
> table, so that the situation is consistent in the other direction.
Yes, I've also considered this option when thinking about this thread,
but forcing a constraint creation up to the parent felt non-intuitive
to me as we force creation of catalog entries on the children based on
the state of the parent for basically everything else. So introducing
a new path where we would do the reverse is a recipe for more complex
code in tablecmds.c, which I'd rather avoid.
> Here's a proposed patch for master only. It turns all three situations
> being reported into ereport(ERROR); in one case I have an XXX comment,
> because we have an alternative when attaching a partition that already
> has a PK to a partitioned table that has a non-PK index: just create a
> separate index in the partition. But that would cause slowness, which
> is probably undesirable. I'm inclined to just remove the XXX comment,
> but if anyone has other thoughts, they are welcome.
An error sounds saner here in the long term.
Tests for all of the code paths involved, perhaps? ;)
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-06-29 04:37:12 | Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert |
Previous Message | Tom Lane | 2024-06-28 20:38:23 | Re: BUG #18526: 'UPDATE' inconsistency using index scan with 'NOT EXIST' after upgrading to PostgreSQL 16 |