Re: pg_plan_advice

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, "heikki(dot)linnakangas" <heikki(dot)linnakangas(at)iki(dot)fi>
Subject: Re: pg_plan_advice
Date: 2026-04-07 22:05:47
Message-ID: 2672940.1775599547@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 0001 and 0002 implement the "retry a few times" idea for avoiding
> test_plan_advice failures. I argue that (a) these are reasonable
> post-commit stabilization that should not be blocked by feature freeze
> and (b) most people here will be happier with a solution like this
> that will normally cost very little than they will be with switching
> test_plan_advice to executing serially. The RMT can decide whether it
> agrees.

I'm not on the RMT, but I agree this is a nicer solution.
(I didn't read these patches in detail, but in a quick once-over
they seemed plausible.)

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-04-07 22:19:06 Re: Stack-based tracking of per-node WAL/buffer usage
Previous Message Andreas Karlsson 2026-04-07 21:59:24 Re: doc: Improve wal_level and effective_wal_level GUC around logical replication