From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>, Lukas Fittl <lukas@fittl.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_plan_advice
In-reply-to: 
 <CA+TgmoadkuOMJjvYe2h6aznHFeePprGEQ8CgUpRK=47sB6DMAg@mail.gmail.com>
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=04U0A!
 D6c65RA@mail.gmail.com> <3683430.1775173413@sss.pgh.pa.us>
 <CA+TgmoazotFpQfGL=eTAZsFQd-_W8nVOG4oDyx5PFkDpH3_Pzg@mail.gmail.com>
 <CA+TgmoadkuOMJjvYe2h6aznHFeePprGEQ8CgUpRK=47sB6DMAg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 03 Apr 2026 13:13:47 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3817824.1775240432.1@sss.pgh.pa.us>
Date: Fri, 03 Apr 2026 14:20:32 -0400
Message-ID: <3817825.1775240432@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3817825.1775240432%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> (In fact, I had a little bit of trouble finding this in the BF results
> even knowing it was there: filtering by test_plan_advice failures
> doesn't find anything recent. sifaka's failure shows up as
> TestModulesCheck-en_US.UTF-8, but frustratingly, the names for the
> stage logs don't seem to quite match the name of what failed. There is
> testmodules-install-check-C and
> testmodules-install-check-en_US.UTF-8, but those have "install" in the
> name and are punctuated differently, so it's not instantly clear that
> it's the same thing. Anyway, I do see it in there now, but what I'm
> saying is that if there have been other failures that are related to
> this, it's possible I have missed them due to stuff like this, so it's
> helpful that you (Tom) pointed this one out.)

I grepped the buildfarm database for 'supplied plan advice' and got
no other hits since 6455e55b0 went in.  That's not a huge sample
size of course, but probably several hundred runs so far.  If there's
another message wording I should check for, let me know.

> Tom, would welcome your thoughts, if you have any, and anyone else's
> thoughts as well. If none, I'll proceed as described above and update
> when I know more.

I don't like anything in category 1 except (1a) run the test scripts
serially for test_plan_advice.  As I said before, I am strongly
against allowing test_plan_advice to constrain what our tests do.

Another idea in category 2, which I think is a bit different from
any option you listed, is to repeat the "plan without advice, then
again with advice, see if it matches" process up to maybe 5-ish times
before declaring failure.  If it works any one time, then write off
the previous failures as being induced by concurrent activity.
Unlike what you mentioned, this isn't dependent on sinval checks,
which I think are next door to useless in the context of the
regression tests: there's a constant storm of sinval activity going
on, to the point where you might as well figure "check for sinval
arrival" is constant "true".

However, eyeing the calendar, I think the only options that are likely
to be stabilizable before feature freeze are (1a) run the test scripts
serially for test_plan_advice or (3a) throw test_plan_advice away.
I know you don't want to do (3a) and I understand why not.  How much
will (1a) slow things down?

			regards, tom lane