MIME-Version: 1.0
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CA+TgmoYjcBA6dw3nwiyfDzPXTCrxTZPXDMrc2TrDJcL1cPK6iA@mail.gmail.com>
 <CA+TgmoYru-vxoTKfwjQby30r2OkTXfb18Km_=VLs6qk8Akr0-g@mail.gmail.com>
 <CA+Tgmoau7yJtvbeH-0kPt1Q=Gt_ezRdgM35Q1=LT665U_86Etg@mail.gmail.com>
 <1299934.1773938807@sss.pgh.pa.us>
 <CA+TgmobOLrMn5jEinWNPL5SrDH1DPpo3a4j+S6-4yhsZwWgzLg@mail.gmail.com>
 <CA+TgmoZUN8FT1Ah=m6Uis5bHa4FUa+_hMDWtcABG17toEfpiUg@mail.gmail.com>
 <CA+TgmoYh2-kM+tscOz=jVYq9Tf4SRPVqzPojs3KLZcW6E9m1BQ@mail.gmail.com>
 <CA+TgmoaK=4w7-qknUo3QhUJ53pXZq=c=KgZmRyD+k7ytqfmgSg@mail.gmail.com>
 <CAP53Pkz3DSFaaowYvbO5LULf3NhydD_UhHkighfWf6_pwxiqUw@mail.gmail.com>
 <CA+TgmoZ45n5jaNKKgbbj4-kYV8WsPvUn=Z8HnoZ7tUb_p9WKXg@mail.gmail.com>
 <CA+TgmoYuWmN-00Ec5pY7zAcpSFQUQLbgAdVWGR9kOR-HM-fHrA@mail.gmail.com>
 <CAP53Pkzn_wZ-R-cPdD9XSQ9+myPUUsPMMqVBPNG3XWXhgfm1-Q@mail.gmail.com>
 <CA+Tgmobxbju8PrY_NULtPr7b7UShp4+Jqibm2Bou8TVS69gObQ@mail.gmail.com>
 <CA+TgmoZpQDJOz_W34Wkp-JA=MQpzLeV6dsDGt=04U0AD6c65RA@mail.gmail.com>
 <3683430.1775173413@sss.pgh.pa.us>
In-Reply-To: <3683430.1775173413@sss.pgh.pa.us>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 2 Apr 2026 22:08:51 -0400
Message-ID: 
 <CA+TgmoazotFpQfGL=eTAZsFQd-_W8nVOG4oDyx5PFkDpH3_Pzg@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, Lukas Fittl <lukas@fittl.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoazotFpQfGL%3DeTAZsFQd-_W8nVOG4oDyx5PFkDpH3_Pzg%40mail.gmail.com>
Precedence: bulk

Thanks for the report.

On Thu, Apr 2, 2026 at 7:43=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After looking around, I think the likely explanation is that the
> concurrently-run alter_table.sql test feels free to mess with the set
> of indexes on onek.  It doesn't drop onek_unique1, but it does
> momentarily rename it:
>
> ALTER INDEX onek_unique1 RENAME TO attmp_onek_unique1;
> ALTER INDEX attmp_onek_unique1 RENAME TO onek_unique1;

Yeah, the fact that it said /* inapplicable */ strongly supports this
theory. There's only two ways that can happen, and an index not
existing with the expected name is one of them (and the only one
that's possible in a query involving only a single table).

> I've not looked closely at pg_plan_advice, but if it matches indexes
> by name then it seems there's a window here where the advice would
> fail to apply.  Also, further down we find
>
> ALTER TABLE onek ADD CONSTRAINT onek_unique1_constraint UNIQUE (unique1);
> ALTER INDEX onek_unique1_constraint RENAME TO onek_unique1_constraint_foo=
;
> ALTER TABLE onek DROP CONSTRAINT onek_unique1_constraint_foo;
>
> which means there's a window there where there are two plausible
> indexes to choose.  Will test_plan_advice cope if the transient one
> is chosen?

It's going to be unhappy if the second planning cycle is incapable of
choosing the same index that the first planning cycle did. I have to
admit that it didn't occur to me that our regression tests would do
something like this. I figured they had to be operating on mostly
independent objects or things would already be broken, but I failed to
consider the possibility that there could be concurrent DDL of a sort
that wouldn't affect the normal running of the regression tests but
would affect pg_plan_advice. Or at least, if I did ever consider it, I
stopped considering it when test_plan_advice appeared to be passing.

> So I'm not sure what to do here, but we have a problem.

I'm not sure, either, and I agree that we have a problem. I'll give it
some more thought tomorrow.

--=20
Robert Haas
EDB: http://www.enterprisedb.com