| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <joe(at)crunchydata(dot)com> |
| Subject: | Re: New Object Access Type hooks |
| Date: | 2022-04-04 20:50:40 |
| Message-ID: | CB068A27-E0CA-4AF6-A5EF-4A0F216AEB5F@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Apr 4, 2022, at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Yeah, it's plausible to get a failure on either the write or read side
> depending on timing.
>
> Perhaps libpq should be trying harder to make those cases look alike, but
> this test is about server behavior not libpq behavior, so I'm inclined
> to just make it lax.
+1.
I've gotten this test failure only a few times in perhaps the last six months, so if we narrow the opportunity for test failure without closing it entirely, we're just making the test failures that much harder to diagnose.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-04-04 21:06:10 | Re: shared-memory based stats collector - v68 |
| Previous Message | Tom Lane | 2022-04-04 20:47:04 | Re: New Object Access Type hooks |