Re: Parallel tests publication and subscription might fail due to concurrent tuple update

On Mon, 17 Mar 2025 at 05:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
> > On Sun, 15 Dec 2024 at 10:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> >> shows that the subscription and publication tests are not concurrent-safe,
> >> because modifying the same pg_database entry might fail with the "tuple
> >> concurrently updated" error.
>
> > This seems related to this thread about concurrency issues in
> > ALTER/DROP SUBSCRIPTION[1], except that this is for GRANT/REVOKE it
> > seems.
>
> > The easiest way to address the flakiness of this test though is
> > probably to just don't run these tests in in parallel. See attached.
>
> I grepped through the buildfarm logs and discovered that desman's
> run of 2024-12-09 18:33:49 is the *only* such failure recorded
> in the last year. What's more, that run was on v16 not master.
>
> So now I'm inclined to think that "do nothing" is the right answer.
> It would be kind of sad to lose all parallelism for these two
> tests, and one-failure-per-year is surely below our noise threshold.
> (Mind you, I'd love to be in a position where that sort of failure
> rate does make it onto our radar. But we're not there today.)
> The fact that it's only been seen on v16 may well mean that subsequent
> changes in one or the other test have further reduced the failure
> probability, too.
>
> Also, we'd be unlikely to remember to undo this change if anyone
> ever fixes the GRANT/REVOKE race condition. It seems possible that
> someone will get annoyed enough with that to make it happen, because
> we've seen related field complaints.
>
> So on the whole I want to reject this. We can reconsider if we
> see more such failures, of course.

I suggest we close the commitfest entry at [1] and create a new one if
we encounter this buildfarm failure again.
[1] - https://commitfest.postgresql.org/patch/5459/

Regards,
Vignesh