On Fri, Jan 27, 2023 at 1:30 PM Michael Paquier <michael@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.