BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access |
Date | |
Msg-id | 17877-4bcc658e33df6de1@postgresql.org Whole thread Raw |
Responses |
Re: BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17877 Logged by: Alexander Lakhin Email address: exclusion@gmail.com PostgreSQL version: 15.2 Operating system: Ubuntu 22.04 Description: The following query: CREATE TABLE pt(tid oid, id int, PRIMARY KEY(tid, id)); CREATE TABLE ft(id int, FOREIGN KEY (tableoid, id) REFERENCES pt); produces a valgrind-detected error: ==00:00:00:04.173 3911860== Invalid read of size 1 ==00:00:00:04.173 3911860== at 0x3B032C: ATAddForeignKeyConstraint (tablecmds.c:9242) ==00:00:00:04.173 3911860== by 0x3B2132: ATExecAddConstraint (tablecmds.c:8875) ==00:00:00:04.173 3911860== by 0x3B8D73: ATExecCmd (tablecmds.c:5031) ==00:00:00:04.173 3911860== by 0x3B93F5: ATRewriteCatalogs (tablecmds.c:4874) ==00:00:00:04.173 3911860== by 0x3B9613: ATController (tablecmds.c:4451) ==00:00:00:04.173 3911860== by 0x3B969D: AlterTable (tablecmds.c:4097) ==00:00:00:04.173 3911860== by 0x596AD6: ProcessUtilitySlow (utility.c:1325) ==00:00:00:04.173 3911860== by 0x596584: standard_ProcessUtility (utility.c:1074) ==00:00:00:04.173 3911860== by 0x59666D: ProcessUtility (utility.c:530) ==00:00:00:04.173 3911860== by 0x59696B: ProcessUtilitySlow (utility.c:1252) ==00:00:00:04.173 3911860== by 0x596584: standard_ProcessUtility (utility.c:1074) ==00:00:00:04.173 3911860== by 0x59666D: ProcessUtility (utility.c:530) ==00:00:00:04.173 3911860== Address 0x4bf512dc is 113,516 bytes inside a recently re-allocated block of size 524,288 alloc'd ... 2023-03-29 16:00:29.068 MSK|||64243669.3bb06e|LOG: server process (PID 3911860) exited with exit code 1 2023-03-29 16:00:29.068 MSK|||64243669.3bb06e|DETAIL: Failed process was running: CREATE TABLE ft(id int, FOREIGN KEY (tableoid, id) REFERENCES pt); Here in ATAddForeignKeyConstraint(): /* * Check some things for generated columns. */ for (i = 0; i < numfks; i++) { char attgenerated = TupleDescAttr(RelationGetDescr(rel), fkattnum[i] - 1)->attgenerated; if (attgenerated) ... we have fkattnum[i] = -6 for the attribute "tableoid", but TupleDescAttr() can't handle system attributes. I've looked at fc22b6623 and found no other TupleDescAttr() calls where attnum can be negative. Though maybe it is a nonsense to use tableoid in a such way. But if not, someone can try to move on without valgrind: CREATE TABLE pt(tid oid, id int, PRIMARY KEY(tid, id)); CREATE TABLE ft(id int, FOREIGN KEY (tableoid, id) REFERENCES pt); INSERT INTO pt SELECT oid, 1 FROM pg_class WHERE relname = 'ft'; INSERT INTO ft VALUES(1); and get: ... #5 0x0000557485037238 in ExceptionalCondition (conditionName=0x557485245f18 "attnum > 0", errorType=0x557485245f0c "BadArgument", fileName=0x557485245ee0 "../../../../src/include/executor/tuptable.h", lineNumber=369) at assert.c:69 #6 0x0000557484f93846 in slot_attisnull (slot=0x557485e64420, attnum=-6) at ../../../../src/include/executor/tuptable.h:369 #7 0x0000557484f9913c in ri_NullCheck (tupDesc=0x7fa297361aa8, slot=0x557485e64420, riinfo=0x557485e7ab80, rel_is_pk=false) at ri_triggers.c:2648 #8 0x0000557484f93bad in RI_FKey_check (trigdata=0x7fffc6ac8980) at ri_triggers.c:280 #9 0x0000557484f940db in RI_FKey_check_ins (fcinfo=0x7fffc6ac87c0) at ri_triggers.c:434 #10 0x0000557484bb9baf in ExecCallTriggerFunc (trigdata=0x7fffc6ac8980, tgindx=0, finfo=0x557485e63878, instr=0x0, per_tuple_context=0x557485e70f60) at trigger.c:2435 #11 0x0000557484bbd653 in AfterTriggerExecute (estate=0x557485e62ff0, event=0x557485e6f090, relInfo=0x557485e63480, src_relInfo=0x557485e63480, dst_relInfo=0x557485e63480, trigdesc=0x557485e63698, finfo=0x557485e63878, instr=0x0, per_tuple_context=0x557485e70f60, trig_tuple_slot1=0x0, trig_tuple_slot2=0x0) at trigger.c:4546 #12 0x0000557484bbdc68 in afterTriggerInvokeEvents (events=0x557485d8bdb0, firing_id=1, estate=0x557485e62ff0, delete_ok=false) at trigger.c:4785 #13 0x0000557484bbe5b5 in AfterTriggerEndQuery (estate=0x557485e62ff0) at trigger.c:5140 #14 0x0000557484bf696b in standard_ExecutorFinish (queryDesc=0x557485e53c60) at execMain.c:438 #15 0x0000557484bf6821 in ExecutorFinish (queryDesc=0x557485e53c60) at execMain.c:406 #16 0x0000557484e6f649 in ProcessQuery (plan=0x557485e48798, sourceText=0x557485d68870 "INSERT INTO ft VALUES(1);", params=0x0, queryEnv=0x0, dest=0x557485e48888, qc=0x7fffc6ac8e10) at pquery.c:193
pgsql-bugs by date: