MIME-Version: 1.0
References: <CA+HiwqFpZ80UJKr4tZus4Omgg7YESzFXKSwSHRW2Ap2=XSVyUA@mail.gmail.com>
 <CA+HiwqH45ZCQkWoLzjOyS6bQ9QsF7yDCKVwiEUtB_RwPFwLmQg@mail.gmail.com>
 <CA+HiwqHRRFQN6yZ54fBydOTM6ncqZBCmewZ6n519RjRdDsO44g@mail.gmail.com>
 <54c35fb9-da3a-4754-ab8c-46ed0b612465@vondra.me> <CA+HiwqH8N-SxEB6SysEBsYNgV_KJs66k9Z2SNmqVzbBP-60yWg@mail.gmail.com>
 <684c70d7-180e-461d-9377-600c2db581ba@vondra.me> <CA+HiwqEmG9YCQvG6uux7sO=jKFSAW6hA4Ea-ymfD+JhJAe4PWQ@mail.gmail.com>
 <CA+HiwqE2FfJfH=siLiR3kJ13tmXZORAGTWsZc2r52o1_5BDv+g@mail.gmail.com>
 <bfcc1b78-aa39-4356-8f42-b8cfb9733d6e@vondra.me> <CA+HiwqFhkpXHAA=4NY5SqYXX08uq=nYtXcSByNZF=2MAy1UA7A@mail.gmail.com>
 <CA+HiwqHCcSoYfpMjFshaU1bj6NjreiDvMSDpVSeBmqk-kbWrPw@mail.gmail.com>
 <CA+HiwqHOejJk0_qMuM5g38h70hY_JvHMAKwnH3k=urfTXauPQA@mail.gmail.com>
 <CA+HiwqFsGKM82oaMby3VWYXf_XFpDAMeT+6SXgj-45HpTrS1dA@mail.gmail.com>
 <CA+HiwqFA5hUWYktt3VMh4zQOYMxqH-MpdX8eemfM+o-9dY-zbQ@mail.gmail.com>
 <CA+HiwqEn7bbUXaXO=SmUujBjJSHfS31cwQroHRBwT0sR=66bgg@mail.gmail.com>
 <e72c94d9-e5f9-4753-9bc1-69d72bd54b8a@gmail.com> <CA+HiwqG=gZZCmpR5VMnXYCm0JDxH3dOwiPngnMLCYTj1unWh0w@mail.gmail.com>
In-Reply-To: <CA+HiwqG=gZZCmpR5VMnXYCm0JDxH3dOwiPngnMLCYTj1unWh0w@mail.gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
Date: Sun, 16 Feb 2025 12:37:07 +0800
Message-ID: <CAEG8a3LN1EWQ2c9Qh2-AHAUKbnXYGforhDg_-OBdxGiZpp7+BQ@mail.gmail.com>
Subject: Re: generic plans and "initial" pruning
To: Amit Langote <amitlangote09@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Tomas Vondra <tomas@vondra.me>, 
	Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 
	Andres Freund <andres@anarazel.de>, Daniel Gustafsson <daniel@yesql.se>, 
	David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, 
	Thom Brown <thom@linux.com>, Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAEG8a3LN1EWQ2c9Qh2-AHAUKbnXYGforhDg_-OBdxGiZpp7%2BBQ%40mail.gmail.com>
Precedence: bulk

Hi Amit,

On Sat, Feb 15, 2025 at 3:51=E2=80=AFPM Amit Langote <amitlangote09@gmail.c=
om> wrote:
>
> Hi Alexander,
>
> On Sat, Feb 15, 2025 at 6:00=E2=80=AFAM Alexander Lakhin <exclusion@gmail=
.com> wrote:
> >
> > Hello Amit,
> >
> > 06.02.2025 04:35, Amit Langote wrote:
> >
> > I plan to push 0001 tomorrow, barring any objections.
> >
> >
> > Please try the following script:
> > CREATE TABLE pt (a int, b int) PARTITION BY range (a);
> > CREATE TABLE tp1 PARTITION OF pt FOR VALUES FROM (1) TO (2);
> > CREATE TABLE tp2 PARTITION OF pt FOR VALUES FROM (2) TO (3);
> >
> > MERGE INTO pt
> > USING (SELECT pg_backend_pid() AS pid) AS q JOIN tp1 ON (q.pid =3D tp1.=
a)
> > ON pt.a =3D tp1.a
> > WHEN MATCHED THEN DELETE;
> >
> > which fails for me with segfault:
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  ExecInitMerge (mtstate=3D0x5a9b9fbccae0, estate=3D0x5a9b9fbcbe20) a=
t nodeModifyTable.c:3680
> > 3680                    relationDesc =3D RelationGetDescr(resultRelInfo=
->ri_RelationDesc);
> > (gdb) bt
> > #0  ExecInitMerge (mtstate=3D0x5a9b9fbccae0, estate=3D0x5a9b9fbcbe20) a=
t nodeModifyTable.c:3680
> > #1  0x00005a9b67e6dfb5 in ExecInitModifyTable (node=3D0x5a9b9fbd5858, e=
state=3D0x5a9b9fbcbe20, eflags=3D0) at nodeModifyTable.c:4906
> > #2  0x00005a9b67e273f7 in ExecInitNode (node=3D0x5a9b9fbd5858, estate=
=3D0x5a9b9fbcbe20, eflags=3D0) at execProcnode.c:177
> > #3  0x00005a9b67e1b9d2 in InitPlan (queryDesc=3D0x5a9b9fbb9970, eflags=
=3D0) at execMain.c:1092
> > #4  0x00005a9b67e1a524 in standard_ExecutorStart (queryDesc=3D0x5a9b9fb=
b9970, eflags=3D0) at execMain.c:268
> > #5  0x00005a9b67e1a223 in ExecutorStart (queryDesc=3D0x5a9b9fbb9970, ef=
lags=3D0) at execMain.c:142
> > ...
> >
> > starting from cbc127917.
> >
> > (I've discovered this anomaly with SQLsmith.)
>
> Thanks! It looks like I missed updating the MERGE-related lists in Modify=
Table.
>
> I've attached a fix with a test added based on your example. I plan to
> push this on Monday.
>

I applied the patch and the problem solved, I have a small question that
should the following line

```
if (node->mergeActionLists =3D=3D NIL)
```

be changed to

```
if (mtstate->mt_mergeActionLists =3D=3D NIL)
```

ISTM that if we have pruned all the merge actions, there is no harm we
omit setting mtstate->mt_merge_subcommands to 0.

> --
> Thanks, Amit Langote


--=20
Regards
Junwang Zhao