Re: ALTER TABLE SET ACCESS METHOD on partitioned tables - Mailing list pgsql-hackers
From | Alexander Lakhin |
---|---|
Subject | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |
Date | |
Msg-id | e5516ac1-5264-c3c0-d822-9e6f614ea93b@gmail.com Whole thread Raw |
In response to | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Responses |
Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
|
List | pgsql-hackers |
Hello Alvaro, 21.03.2024 15:07, Alvaro Herrera wrote: > Given that Michaël is temporarily gone, I propose to push the attached > tomorrow. Please look at a new anomaly introduced with 374c7a229. Starting from that commit, the following erroneous query: CREATE FOREIGN TABLE fp PARTITION OF pg_am DEFAULT SERVER x; triggers an assertion failure: TRAP: failed Assert("relation->rd_rel->relam == InvalidOid"), File: "relcache.c", Line: 1219, PID: 3706301 with the stack trace: ... #4 0x00007fe53ced67f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x000055f28555951e in ExceptionalCondition (conditionName=conditionName@entry=0x55f285744788 "relation->rd_rel->relam == InvalidOid", fileName=fileName@entry=0x55f285743f1c "relcache.c", lineNumber=lineNumber@entry=1219) at assert.c:66 #6 0x000055f285550450 in RelationBuildDesc (targetRelId=targetRelId@entry=16385, insertIt=insertIt@entry=false) at relcache.c:1219 #7 0x000055f285550769 in RelationClearRelation (relation=relation@entry=0x7fe5310dd178, rebuild=rebuild@entry=true) at relcache.c:2667 #8 0x000055f285550c41 in RelationFlushRelation (relation=0x7fe5310dd178) at relcache.c:2850 #9 0x000055f285550ca0 in RelationCacheInvalidateEntry (relationId=<optimized out>) at relcache.c:2921 #10 0x000055f285542551 in LocalExecuteInvalidationMessage (msg=0x55f2861b3160) at inval.c:738 #11 0x000055f28554159b in ProcessInvalidationMessages (group=0x55f2861b2e6c, func=func@entry=0x55f2855424a8 <LocalExecuteInvalidationMessage>) at inval.c:518 #12 0x000055f285542740 in CommandEndInvalidationMessages () at inval.c:1180 #13 0x000055f28509cbbd in AtCCI_LocalCache () at xact.c:1550 #14 0x000055f28509e88e in CommandCounterIncrement () at xact.c:1116 #15 0x000055f2851d0c8b in DefineRelation (stmt=stmt@entry=0x55f2861803b0, relkind=relkind@entry=102 'f', ownerId=10, ownerId@entry=0, typaddress=typaddress@entry=0x0, queryString=queryString@entry=0x55f28617f870 "CREATE FOREIGN TABLE fp PARTITION OF pg_am DEFAULT SERVER x;") at tablecmds.c:1008 #16 0x000055f28540945d in ProcessUtilitySlow (pstate=pstate@entry=0x55f2861a9dc0, pstmt=pstmt@entry=0x55f286180510, queryString=queryString@entry=0x55f28617f870 "CREATE FOREIGN TABLE fp PARTITION OF pg_am DEFAULT SERVER x;", context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=params@entry=0x0, queryEnv=queryEnv@entry=0x0, dest=0x55f2861807d0, qc=0x7fff15b5d7c0) at utility.c:1203 #17 0x000055f28540911f in standard_ProcessUtility (pstmt=0x55f286180510, queryString=0x55f28617f870 "CREATE FOREIGN TABLE fp PARTITION OF pg_am DEFAULT SERVER x;", readOnlyTree=<optimized out>, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x55f2861807d0, qc=0x7fff15b5d7c0) at utility.c:1067 ... On 374c7a229~1 it fails with ERROR: "pg_am" is not partitioned Best regards, Alexander
pgsql-hackers by date: