Re: Add arbitrary xid and mxid to pg_resetwal - Mailing list pgsql-hackers

From Daniil Davydov
Subject Re: Add arbitrary xid and mxid to pg_resetwal
Date
Msg-id CAJDiXggzZJzL7saT1TO-PcqoZbw+s33htd6_Ti1NLjqkx4sr2Q@mail.gmail.com
Whole thread Raw
In response to Re: Add arbitrary xid and mxid to pg_resetwal  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi,

On Fri, Mar 7, 2025 at 9:35 PM Aleksander Alekseev
<aleksander@timescale.com> wrote:
> Your patch should target the `master` branch. Also please add a
> corresponding entry to the nearest open commitfest [1].

OK, thanks for the notice! I attach the v2 patch for the `master`
branch to this letter. Now you can also find it in commitfest in
System Administration topic.

On Fri, Mar 7, 2025 at 9:35 PM Aleksander Alekseev
<aleksander@timescale.com> wrote:
> > In my opinion, this will be useful primarily to simplify testing, since at the moment you have to create segments
manually(as in this article). 
>
> In this case you should add a test or two that demonstrate this. As
> separate commits perhaps.

Well, I just saw that people have a request for such functionality.
More specifically, I think it's worth taking a look at the
src/test/modules/xid_wraparound.
There, the transaction counter is just jumping forward to check the
autovacuum and postgres wraparound limits. These tests are using the
`xid_wraparound` extension, but it can be replaced with
new pg_resetwal feature.
Measurements on my machine showed that the test execution time (with
advancing xid up to 10 billions with 100 millions values by step)
takes 40% less time to complete.

P.S.
v2 patch looks a bit scary, because it contains a lot of raw I/O
operations. At the moment, it is the best I came up with, but the
logic of the code (I hope) is correct.

--
Best regards,
Daniil Davydov

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Commitfest app release on Feb 17 with many improvements
Next
From: vignesh C
Date:
Subject: Re: Commit fest 2025-03