From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Cc: Junwang Zhao <zhjwpku@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Guillaume Lelarge <guillaume@lelarge.info>
Cc: Michael Paquier <michael@paquier.xyz>
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date: Fri, 25 Oct 2024 17:14:37 +0200
Message-ID: <202410251514.5yabwwj2uc2e@alvherre.pgsql> (raw)
In-Reply-To: <a6b7545b-a99a-7009-8161-0ac149efec3f@gmail.com>
On 2024-Oct-25, Alexander Lakhin wrote:
> I've also discovered another anomaly with a similar setup, but it's not
> related to 53af9491a.
Hmm, it may well be a preexisting problem, but I do think it involves
the same code. As far as I can tell, the value "2" here
> This script ends up with:
> ERROR: invalid attribute number 2
> ERROR: cache lookup failed for attribute 2 of relation 16398
is coming from riinfo->confdelsetcols which was set up by
DetachPartitionFinalize during the last DETACH operation.
> (Perhaps it deserves a separate discussion.)
No need for that.
A backtrace from the errfinish gives me this (apologies for the
wide terminal):
#0 errfinish (filename=0x5610d93e4510 "../../../../../pgsql/source/master/src/backend/parser/parse_relation.c", lineno=3618,
funcname=0x5610d93e5518 <__func__.5> "attnumAttName") at ../../../../../../pgsql/source/master/src/backend/utils/error/elog.c:475
#1 0x00005610d8d68bcc in attnumAttName (rd=rd@entry=0x7f69dd0c1a90, attid=2) at ../../../../../pgsql/source/master/src/backend/parser/parse_relation.c:3618
#2 0x00005610d924a8c5 in ri_set (trigdata=0x7ffe38d924c0, is_set_null=<optimized out>, tgkind=<optimized out>)
at ../../../../../../pgsql/source/master/src/backend/utils/adt/ri_triggers.c:1219
#3 0x00005610d8f897ea in ExecCallTriggerFunc (trigdata=trigdata@entry=0x7ffe38d924c0, tgindx=tgindx@entry=2, finfo=0x5611153f5768, finfo@entry=0x5611153f5708,
instr=instr@entry=0x0, per_tuple_context=per_tuple_context@entry=0x561115471c30) at ../../../../../pgsql/source/master/src/backend/commands/trigger.c:2362
#4 0x00005610d8f8b646 in AfterTriggerExecute (trig_tuple_slot2=0x0, trig_tuple_slot1=0x0, per_tuple_context=0x561115471c30, instr=0x0, finfo=0x5611153f5708,
trigdesc=0x5611153f53e8, dst_relInfo=<optimized out>, src_relInfo=<optimized out>, relInfo=0x5611153f51d8, event=0x56111546fd4c, estate=0x5611153f4d50)
at ../../../../../pgsql/source/master/src/backend/commands/trigger.c:4498
#5 afterTriggerInvokeEvents (events=events@entry=0x5611154292a0, firing_id=1, estate=estate@entry=0x5611153f4d50, delete_ok=delete_ok@entry=false)
at ../../../../../pgsql/source/master/src/backend/commands/trigger.c:4735
#6 0x00005610d8f8ff10 in AfterTriggerEndQuery (estate=estate@entry=0x5611153f4d50) at ../../../../../pgsql/source/master/src/backend/commands/trigger.c:5090
#7 0x00005610d8fb2457 in standard_ExecutorFinish (queryDesc=0x561115460810) at ../../../../../pgsql/source/master/src/backend/executor/execMain.c:442
#8 0x00005610d917df48 in ProcessQuery (plan=0x56111545ef50, sourceText=0x56111539cfb0 "DELETE FROM t;", params=0x0, queryEnv=0x0, dest=0x56111545f0b0,
qc=0x7ffe38d92830) at ../../../../../pgsql/source/master/src/backend/tcop/pquery.c:193
and then
(gdb) frame 2
#2 0x00005610d924a8c5 in ri_set (trigdata=0x7ffe38d924c0, is_set_null=<optimized out>, tgkind=<optimized out>)
at ../../../../../../pgsql/source/master/src/backend/utils/adt/ri_triggers.c:1219
1219 quoteOneName(attname, RIAttName(fk_rel, set_cols[i]));
(gdb) print *riinfo
$5 = {constraint_id = 16400, valid = true, constraint_root_id = 16400, oidHashValue = 3001019032, rootHashValue = 3001019032, conname = {
data = "pt_a_fkey", '\000' <repeats 54 times>}, pk_relid = 16384, fk_relid = 16397, confupdtype = 97 'a', confdeltype = 100 'd', ndelsetcols = 1,
confdelsetcols = {2, 0 <repeats 31 times>}, confmatchtype = 115 's', hasperiod = false, nkeys = 1, pk_attnums = {1, 0 <repeats 31 times>}, fk_attnums = {1,
0 <repeats 31 times>}, pf_eq_oprs = {96, 0 <repeats 31 times>}, pp_eq_oprs = {96, 0 <repeats 31 times>}, ff_eq_oprs = {96, 0 <repeats 31 times>},
period_contained_by_oper = 0, agged_period_contained_by_oper = 0, valid_link = {prev = 0x5611153f4c30, next = 0x5610d96b51b0 <ri_constraint_cache_valid_list>}}
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Digital and video cameras have this adjustment and film cameras don't for the
same reason dogs and cats lick themselves: because they can." (Ken Rockwell)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, exclusion@gmail.com, tndrwang@gmail.com, jgdr@dalibo.com, zhjwpku@gmail.com, guillaume@lelarge.info, michael@paquier.xyz
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
In-Reply-To: <202410251514.5yabwwj2uc2e@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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