Thread: Add arbitrary xid and mxid to pg_resetwal
Hi,
I prepared a patch that will allow us to set arbitrary values in -m and -x options for pg_resetwal. For now, it is not possible to specify a value that does not fit into existing SLRU segments, and
main idea of this patch (for REL_17_STABLE) is to create such segments inside pg_resetwal's main() function.
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).
Patch also contains additional tests for pg_resetwal (regression is called to make sure that all postgres components are working correctly, but maybe it can be replaced with something more "compact").
What do you think about the idea of adding such functionality?
--
Best regards,
Daniil Davydov
Attachment
Hi Daniil, Thanks for the patch. > main idea of this patch (for REL_17_STABLE) Your patch should target the `master` branch. Also please add a corresponding entry to the nearest open commitfest [1]. > 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. If you could also demonstrate that these tests improve code coverage for instance that would be great. [1]: https://commitfest.postgresql.org/ -- Best regards, Aleksander Alekseev
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