pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
5+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2024-07-24 3dd637f3d5 08b6a9ecf9 ed74309755 2b22543a44 084814d888 f74fac06c6 fe1d16f663 Reset relhassubclass upon attaching table as a partition
* BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
@ 2024-07-23 13:00 PG Bug reporting form <noreply@postgresql.org>
2024-07-23 16:35 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: PG Bug reporting form @ 2024-07-23 13:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 18550
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 17beta2
Operating system: Ubuntu 22.04
Description:
The following script:
CREATE TABLE t1 (a int);
CREATE TABLE t2 () INHERITS (t1);
DROP TABLE t2;
CREATE TABLE t (a int) PARTITION BY LIST (a);
ALTER TABLE t ATTACH PARTITION t1 FOR VALUES IN (1);
INSERT INTO t1 VALUES (1);
UPDATE t1 SET a = 2 WHERE a = 1
triggers an assertion failure (due to t1 is not recognized as a leaf
partition):
TRAP: failed Assert("rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE"),
File: "partdesc.c", Line: 73, PID: 37464
ExceptionalCondition at assert.c:52:13
RelationGetPartitionDesc at partdesc.c:83:6
PartitionDirectoryLookup at partdesc.c:458:11
ExecInitPartitionDispatchInfo at execPartition.c:1128:13
ExecSetupPartitionTupleRouting at execPartition.c:240:9
ExecCrossPartitionUpdate at nodeModifyTable.c:1791:39
ExecUpdateAct at nodeModifyTable.c:2046:7
ExecUpdate at nodeModifyTable.c:2336:12
ExecModifyTable at nodeModifyTable.c:4114:12
ExecProcNodeFirst at execProcnode.c:465:1
ExecProcNode at executor.h:275:1
ExecutePlan at execMain.c:1646:10
standard_ExecutorRun at execMain.c:363:3
ExecutorRun at execMain.c:305:1
ProcessQuery at pquery.c:165:5
PortalRunMulti at pquery.c:1277:5
PortalRun at pquery.c:795:5
Reproduced on REL_14_STABLE (starting from 8f4a6b9e4) .. master.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
2024-07-23 13:00 BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure PG Bug reporting form <noreply@postgresql.org>
@ 2024-07-23 16:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-07-23 17:21 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2024-07-23 16:35 UTC (permalink / raw)
To: exclusion@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t1 (a int);
> CREATE TABLE t2 () INHERITS (t1);
> DROP TABLE t2;
> CREATE TABLE t (a int) PARTITION BY LIST (a);
> ALTER TABLE t ATTACH PARTITION t1 FOR VALUES IN (1);
> INSERT INTO t1 VALUES (1);
> UPDATE t1 SET a = 2 WHERE a = 1
> triggers an assertion failure (due to t1 is not recognized as a leaf
> partition):
> TRAP: failed Assert("rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE"),
Hmm. Without the DROP TABLE, the ATTACH would fail:
regression=# ALTER TABLE t ATTACH PARTITION t1 FOR VALUES IN (1);
ERROR: cannot attach inheritance parent as partition
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.)
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
2024-07-23 13:00 BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure PG Bug reporting form <noreply@postgresql.org>
2024-07-23 16:35 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-07-23 17:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-23 19:38 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Alvaro Herrera @ 2024-07-23 17:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
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/
Attachments:
0001-Reset-relhassubclass-when-attaching-as-a-partition.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
2024-07-23 13:00 BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure PG Bug reporting form <noreply@postgresql.org>
2024-07-23 16:35 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
2024-07-23 17:21 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-07-23 19:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-07-24 10:44 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2024-07-23 19:38 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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).
Looks sane.
> I'd add Alexander's script as a test too, somewhere near the bottom of
> create_table.sql.
Personally I'd include this in the existing alter_table.sql test case,
to save a few steps:
-- check that the table being attached is not part of regular inheritance
CREATE TABLE parent (LIKE list_parted);
CREATE TABLE child () INHERITS (parent);
ALTER TABLE list_parted ATTACH PARTITION child FOR VALUES IN (1);
ERROR: cannot attach inheritance child as partition
ALTER TABLE list_parted ATTACH PARTITION parent FOR VALUES IN (1);
ERROR: cannot attach inheritance parent as partition
+DROP TABLE child;
+-- now it should work
+ALTER TABLE list_parted ATTACH PARTITION parent FOR VALUES IN (1);
+-- test insert/update, per bug #18550
+INSERT INTO parent ...
+UPDATE parent ...
DROP TABLE parent CASCADE;
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure
2024-07-23 13:00 BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure PG Bug reporting form <noreply@postgresql.org>
2024-07-23 16:35 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
2024-07-23 17:21 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-23 19:38 ` Re: BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-07-24 10:44 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 0 replies; 5+ messages in thread
From: Alvaro Herrera @ 2024-07-24 10:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 2024-Jul-23, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Yeah, that seems to work. We can do that essentially for free in
> > StorePartitionBound(), like in the attached (which was taken in 14).
>
> Looks sane.
Thanks for looking.
> > I'd add Alexander's script as a test too, somewhere near the bottom of
> > create_table.sql.
>
> Personally I'd include this in the existing alter_table.sql test case,
> to save a few steps:
Nice! Done that way.
I didn't see the connection between the assertion failure and
8f4a6b9e4f5b, but I didn't spend much time on it. But I didn't see any
reason not to backpatch this all the way down, either, so I did that.
Thanks, Alexander, for reporting this.
--
Álvaro Herrera 48°01'N 7°57'E — 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.
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-07-24 10:44 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-23 13:00 BUG #18550: Cross-partition update of a former inheritance parent leads to an assertion failure PG Bug reporting form <noreply@postgresql.org>
2024-07-23 16:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-07-23 17:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-23 19:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-07-24 10:44 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox