From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrey Borodin <amborodin86(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Something is wrong with wal_compression |
Date: | 2023-01-27 00:46:09 |
Message-ID: | CA+hUKG+OP0vV2Tk1Tf7XjLMhVZ+rH+ES42MHn9=0rVVQFLCD2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 27, 2023 at 1:30 PM Michael Paquier <michael(at)paquier(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-27 01:15:10 | Re: New strategies for freezing, advancing relfrozenxid early |
Previous Message | Michael Paquier | 2023-01-27 00:34:33 | Re: Record queryid when auto_explain.log_verbose is on |