Обсуждение: pgsql: Choose FK name correctly during partition attachment

Поиск
Список
Период
Сортировка

pgsql: Choose FK name correctly during partition attachment

От
Alvaro Herrera
Дата:
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: https://postgr.es/m/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(-)


Re: pgsql: Choose FK name correctly during partition attachment

От
Tom Lane
Дата:
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
expressionopcode 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
readingvariable: Unhandled dwarf expression opcode 0xfa>, cmd=<error reading variable: Unhandled dwarf expression
opcode0xfa>, 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
PARTITIONparted_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
PARTITIONparted_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



Re: pgsql: Choose FK name correctly during partition attachment

От
John Naylor
Дата:
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