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