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>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date: 2024-10-24 15:27:31
Message-ID: CAHewXN=o+cW3iyaMi0Qk101V3cR40G6sQeaOXv90Q89vk7E3Dg@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.
>

Sorry, I can't reproduce this leak on master.

--
Thanks,
Tender Wang

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2024-10-24 15:27:46 Re: general purpose array_sort
Previous Message Fujii Masao 2024-10-24 15:23:15 Re: Refactor GetLockStatusData() by skipping unused backends and groups