Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date: 2024-10-25 06:51:28
Message-ID: CAHewXN=Ut0ijPndwt+FJ1qs6buofz4wn6O4umUd0OcRgOPjORQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexander Lakhin <exclusion(at)gmail(dot)com> 于2024年10月24日周四 22:00写道:

> Hello Alvaro,
>
> 22.10.2024 17:32, Alvaro Herrera wrote:
> > Yeah. I pushed these patches finally, thanks!
>
> Please look at a new anomaly introduced with 53af9491a. When running the
> following script:
> CREATE TABLE t (a int, b int, PRIMARY KEY (a, b));
> CREATE TABLE pt (a int, b int, FOREIGN KEY (a, b) REFERENCES t(a, b))
> PARTITION BY LIST (a);
>
> CREATE TABLE tp1 (x int, a int, b int);
> ALTER TABLE tp1 DROP COLUMN x;
>
> ALTER TABLE pt ATTACH PARTITION tp1 FOR VALUES IN (1);
>
> ALTER TABLE pt DETACH PARTITION tp1;
>
> I get a memory access error detected by Valgrind:
> 2024-10-24 12:05:04.645 UTC [1079077] LOG: statement: ALTER TABLE pt
> DETACH PARTITION tp1;
> ==00:00:00:07.887 1079077== Invalid read of size 2
> ==00:00:00:07.887 1079077== at 0x4A61DD: DetachPartitionFinalize
> (tablecmds.c:19545)
> ==00:00:00:07.887 1079077== by 0x4A5C11: ATExecDetachPartition
> (tablecmds.c:19386)
> ==00:00:00:07.887 1079077== by 0x48561E: ATExecCmd (tablecmds.c:5540)
> ==00:00:00:07.887 1079077== by 0x4845DE: ATRewriteCatalogs
> (tablecmds.c:5203)
> ==00:00:00:07.887 1079077== by 0x4838EC: ATController (tablecmds.c:4758)
> ==00:00:00:07.887 1079077== by 0x4834F1: AlterTable (tablecmds.c:4404)
> ==00:00:00:07.887 1079077== by 0x7D6D52: ProcessUtilitySlow
> (utility.c:1318)
> ==00:00:00:07.887 1079077== by 0x7D65F7: standard_ProcessUtility
> (utility.c:1067)
> ==00:00:00:07.887 1079077== by 0x7D54F7: ProcessUtility (utility.c:523)
> ==00:00:00:07.887 1079077== by 0x7D3D70: PortalRunUtility
> (pquery.c:1158)
> ==00:00:00:07.887 1079077== by 0x7D3FE7: PortalRunMulti (pquery.c:1316)
> ==00:00:00:07.887 1079077== by 0x7D3431: PortalRun (pquery.c:791)
>
> Reproduced on REL_15_STABLE .. master.
>

Thanks for reporting. I can reproduce this memory invalid access on HEAD.
After debuging codes, I found the root cause.
In DetachPartitionFinalize(), below code:
att = TupleDescAttr(RelationGetDescr(partRel),
attmap->attnums[conkey[i] - 1] - 1);

We should use confkey[i] -1 not conkey[i] - 1;
In this case, the length of attmap is 2, conkey= {2,3}, confkey={1,2},
attmap->attnums[conkey[1] -1] will trigger
memory invalid access.

In the block, we process referenced side, so wo should use confkey.
I attach a patch to fix this.

--
Thanks,
Tender Wang

Attachment Content-Type Size
0001-Fix-memory-invalid-access-due-to-using-wrong-conkey.patch application/octet-stream 3.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2024-10-25 07:15:23 Re: cache lookup failed when \d t concurrent with DML change column data type
Previous Message Amit Kapila 2024-10-25 06:37:31 Re: Pgoutput not capturing the generated columns