On Fri, Jan 27, 2023 at 1:30 PM Michael Paquier <mich...@paquier.xyz> wrote: > On Thu, Jan 26, 2023 at 04:14:57PM -0800, Andrey Borodin wrote: > > If we agree that xid allocation is not something persistent, let's fix > > the test? We can replace a check with select * from pg_class or, > > maybe, add an amcheck run. > > As far as I recollect, this test was introduced to test this new > > function in 857ee8e391f. > > My opinion would be to make this function more reliable, FWIW, even if > that involves a performance impact when called in a close loop by > forcing more WAL flushes to ensure its report durability and > consistency. As things stand, this is basically unreliable, and we > document it as something applications can *use*. Adding a note in the > docs to say that this function can be unstable for some edge cases > does not make much sense to me, either. Commit 857ee8e itself says > that we can use it if a database connection is lost, which could > happen on a crash..
Yeah, the other thread has a patch for that. But it would hurt some workloads. A better patch would do some kind of amortisation (reserving N xids at a time or some such scheme, while being careful to make sure the right CLOG pages etc exist if you crash and skip a bunch of xids on recovery) but be more complicated. For the record, back before release 13 added the 64 bit xid allocator, these functions (or rather their txid_XXX ancestors) were broken in a different way: they didn't track epochs reliably, the discovery of which led to the new xid8-based functions, so that might provide a natural back-patching range, if a back-patchable solution can be agreed on.
