Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
Date
Msg-id 202407231721.772zsh7kjvki@alvherre.pgsql
Whole thread Raw
In response to Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
List pgsql-bugs
On 2024-Jul-23, Tom Lane wrote:

> I observe that in the case given, t1 still has pg_class.relhassubclass
> true after the ATTACH PARTITION.  Maybe it'd be wise to force that
> false after verifying there are no subclasses?  (I tried fixing it
> manually, and that prevents the assertion crash.)

Yeah, that seems to work.  We can do that essentially for free in
StorePartitionBound(), like in the attached (which was taken in 14).

I'd add Alexander's script as a test too, somewhere near the bottom of
create_table.sql.


If the affected table is a foreign table, it doesn't seem to have the
same problem (I tried using contrib_regression's ft1 as t1 in
Alexander's script).  I suspect that's because we assume somewhere that
foreign tables are not in turn partitioned.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup
Next
From: Tom Lane
Date:
Subject: Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure