On Mon, 17 Mar 2025 at 05:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Jelte Fennema-Nio <postg...@jeltef.nl> writes: > > On Sun, 15 Dec 2024 at 10:00, Alexander Lakhin <exclus...@gmail.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
