pgsql: Choose FK name correctly during partition attachment
Choose FK name correctly during partition attachment
During ALTER TABLE ATTACH PARTITION, if the name of a parent's foreign
key constraint is already used on the partition, the code tries to
choose another one before the FK attributes list has been populated,
so the resulting constraint name was "<relname>__fkey" instead of
"<relname>_<attrs>_fkey". Repair, and add a test case.
Backpatch to 12. In 11, the code to attach a partition was not smart
enough to cope with conflicting constraint names, so the problem doesn't
exist there.
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Discussion: /messages/by-id/20220901184156.738ebee5@karst
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e7936f8b3e57046c0e178ccefa04ac7e6fbae79c
Modified Files
--------------
src/backend/commands/tablecmds.c | 20 ++++++++++----------
src/test/regress/expected/constraints.out | 23 +++++++++++++++++++++++
src/test/regress/sql/constraints.sql | 19 +++++++++++++++++++
3 files changed, 52 insertions(+), 10 deletions(-)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Choose FK name correctly during partition attachment
Some of the buildfarm is unhappy with this, most clearly so here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-08%2015%3A30%3A25
ore was generated by `postgres: postgres regression [local] ALTER TABLE '.
Program terminated with signal 6, Aborted.
#0 0x2a460417 in raise () from /lib/i386-linux-gnu/libc.so.6
#0 0x2a460417 in raise () from /lib/i386-linux-gnu/libc.so.6
#1 0x2a463802 in abort () from /lib/i386-linux-gnu/libc.so.6
#2 0x0864edf8 in ExceptionalCondition (conditionName=conditionName@entry=0x878fc10 "*updateTriggerOid == InvalidOid", errorType=errorType@entry=0x86b174f "FailedAssertion", fileName=fileName@entry=0x878f1bb "tablecmds.c", lineNumber=lineNumber@entry=10591) at assert.c:69
#3 0x082e7c57 in GetForeignKeyActionTriggers (updateTriggerOid=<synthetic pointer>, deleteTriggerOid=<synthetic pointer>, conrelid=21128, confrelid=21128, conoid=21141, trigrel=0x213c28f0) at tablecmds.c:10591
#4 CloneFkReferenced (partitionRel=partitionRel@entry=0x212beb5c, parentRel=<error reading variable: Unhandled dwarf expression opcode 0xfa>, parentRel=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at tablecmds.c:10117
#5 0x082f19e9 in CloneForeignKeyConstraints (wqueue=0xffd430c0, parentRel=0x212b6a98, partitionRel=0x212beb5c) at tablecmds.c:9955
#6 0x082fc8c8 in ATExecAttachPartition (wqueue=wqueue@entry=0xffd430c0, rel=rel@entry=0x212b6a98, context=<error reading variable: Unhandled dwarf expression opcode 0xfa>, cmd=<error reading variable: Unhandled dwarf expression opcode 0xfa>, cmd=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at tablecmds.c:17852
#7 0x082ff709 in ATExecCmd (wqueue=wqueue@entry=0xffd430c0, tab=tab@entry=0x8e44180, cmd=0x8dff454, lockmode=lockmode@entry=4, cur_pass=cur_pass@entry=10, context=context@entry=0xffd43284) at tablecmds.c:5227
#8 0x08300e87 in ATRewriteCatalogs (context=0xffd43284, lockmode=4, wqueue=0xffd430c0) at tablecmds.c:4878
#9 ATController (parsetree=0x8d5d574, parsetree@entry=0x1, rel=<optimized out>, cmds=<optimized out>, recurse=true, lockmode=4, context=0xffd43284) at tablecmds.c:4455
#10 0x08302386 in AlterTable (stmt=0x1, stmt@entry=0x8d5d574, lockmode=lockmode@entry=4, context=0xffd43284, context@entry=0x1) at tablecmds.c:4101
#11 0x084f6ed9 in ProcessUtilitySlow (pstate=pstate@entry=0x8e4dc04, pstmt=pstmt@entry=0x8d5d614, queryString=queryString@entry=0x8d5ca54 "ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR VALUES IN ('1');", context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, qc=0xffd43580, dest=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at utility.c:1325
#12 0x084f5a28 in standard_ProcessUtility (pstmt=0x8d5d614, queryString=0x8d5ca54 "ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR VALUES IN ('1');", readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x8d5d804, qc=0xffd43580) at utility.c:1074
#13 0x084f3c5d in PortalRunUtility (portal=portal@entry=0x8dae354, pstmt=pstmt@entry=0x8d5d614, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=0x8d5d804, qc=0xffd43580) at pquery.c:1158
#14 0x084f3dd5 in PortalRunMulti (portal=0x8dae354, portal@entry=0x8d5d804, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x8d5d804, altdest=altdest@entry=0x8d5d804, qc=qc@entry=0xffd43580) at pquery.c:1322
#15 0x084f4710 in PortalRun (portal=portal@entry=0x8dae354, count=count@entry=2147483647, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=0x8d5d804, altdest=0x8d5d804, qc=qc@entry=0xffd43580) at pquery.c:791
#16 0x084ef82f in exec_simple_query (query_string=query_string@entry=0x8d5ca54 "ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR VALUES IN ('1');") at postgres.c:1235
#17 0x084f0fd7 in PostgresMain (dbname=0x8d83ad4 "regression", username=0x8d5a758 "postgres") at postgres.c:4497
#18 0x080f7de2 in BackendRun (port=<optimized out>) at postmaster.c:4486
#19 BackendStartup (port=0x8d7bd78) at postmaster.c:4214
#20 ServerLoop () at postmaster.c:1804
#21 0x0844dc7c in PostmasterMain (argc=argc@entry=8, argv=argv@entry=0x8d58668) at postmaster.c:1476
#22 0x080faa8f in main (argc=8, argv=0x8d58668) at main.c:197
regards, tom lane
On Fri, Sep 9, 2022 at 1:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Choose FK name correctly during partition attachment
Some of the buildfarm is unhappy with this, most clearly so here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-08%2015%3A30%3A25
I'm seeing a lot more failures now after the Flex/Bison minimum
version bump, but that's a strange correlation. Maybe the above
failure is intermittent?
--
John Naylor
EDB: http://www.enterprisedb.com