| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure |
| Date: | 2024-07-23 17:21:12 |
| Message-ID: | 202407231721.772zsh7kjvki@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| 0001-Reset-relhassubclass-when-attaching-as-a-partition.patch | text/x-diff | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-23 19:38:23 | Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure |
| Previous Message | Tom Lane | 2024-07-23 16:41:57 | Re: BUG #18551: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup |