Re: pg_plan_advice

On Wed, Apr 8, 2026 at 10:49 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Tue, Apr 07, 2026 at 06:05:47PM -0400, Tom Lane wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >
> >> The other question here is whether it's really a good idea to
> >> apply this now considering that we've seen only one failure so far. I
> >> think it's probably a good idea to do something like this before
> >> release, so that we hopefully reduce the false positive rate from the
> >> test to something much closer to zero, but I think we've still had
> >> only the one failure, and I'm really interested in knowing how close
> >> the failure rate is to zero already. The RMT may have an opinion on
> >> how long to wait before doing something like this, too.
> >
> > No strong opinion about that. Certainly waiting a couple of weeks
> > to gather more data seems reasonable.
>
> I am only 1/3 of the RMT, but I am fine with the plan as stated.

I agree with waiting a few weeks to continue catching bugs.

As for 0001/0002 and the retry approach: if that's the best way to
avoid spurious test failures, I'm fine with it. I haven't reviewed the
code in detail and don't have an alternative to suggest. I'm
definitely against running anything serially.

As for the other ideas and suggestions so far:

I don't see a way to split up the regression test suite that wouldn't
make it harder to figure out where to add tests in the future. The
whole point is to avoid regressing pg_plan_advice when new things are
added to the planner, and that works because people don't have to
think about a pg_plan_advice -- their new test queries automatically
get coverage.

I do think there needs to be a way to run this in CI, but it doesn't
have to be on by default.

For the buildfarm, I don't have a strong opinion about whether to
limit it to some animals or some runs. Running on only some animals is
easier to reason about when you see a failure (i.e. that animal runs
with test_plan_advice, so it might be that), but running it once a day
or once a week on all animals gives broader coverage. That said, the
kind of coverage you gain from timing differences across animals --
catching races and transient issues -- may be less relevant for
test_plan_advice than for other tests.

- Melanie