From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: race condition in pg_class |
Date: | 2024-07-28 16:51:32 |
Message-ID: | 20240728165132.01.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 28, 2024 at 11:50:33AM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Sat, Jul 20, 2024 at 11:00:00AM +0300, Alexander Lakhin wrote:
> >> A recent buildfarm test failure [1] showed that the
> >> intra-grant-inplace-db.spec test added with 0844b3968 may fail
>
> >> But as the test going to be modified by the inplace110-successors-v8.patch
> >> and the modified test (with all three latest patches applied) passes
> >> reliably in the same conditions, maybe this failure doesn't deserve a
> >> deeper exploration.
>
> > Agreed. Let's just wait for code review of the actual bug fix, not develop a
> > separate change to stabilize the test. One flake in three weeks is low enough
> > to make that okay.
>
> It's now up to three similar failures in the past ten days
> Is it time to worry yet? If this were HEAD only, I'd not be too
> concerned; but two of these three are on allegedly-stable branches.
> And we have releases coming up fast.
I don't know; neither decision feels terrible to me. A bug fix that would
address both the data corruption causes and those buildfarm failures has been
awaiting review on this thread for 77 days. The data corruption causes are
more problematic than 0.03% of buildfarm runs getting noise failures. Two
wrongs don't make a right, but a commit masking that level of buildfarm noise
also feels like sending the wrong message.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-07-28 16:59:35 | Re: race condition in pg_class |
Previous Message | Tom Lane | 2024-07-28 16:31:27 | Re: Parent/child context relation in pg_get_backend_memory_contexts() |