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

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.

regards, tom lane