Thread: [PATCH] Add initial xid/mxid/mxoff to initdb
Hi!
During work on 64-bit XID patch [1] we found handy to have initdb options to set initial xid/mxid/mxoff values to arbitrary non default values. It helps test different scenarios: related to wraparound, pg_upgrade from 32-bit XID to 64-bit XID, etc.
We realize, this patch can be singled out as an independent patch from the whole patchset in [1] and be useful irrespective of 64-bit XID in cases of testing of wraparound and so on.
In particular, we employed this patch to test recent changes in logical replication of subxacts [2] and found no problems in it near the point of publisher wraparound.
Please share your opinions and reviews are always welcome.
--
Best regards,
Maxim Orlov.
Attachment
Hi!
CF bot says patch does not apply. Rebased.
Your reviews are very much welcome!
Your reviews are very much welcome!
--
Best regards,
Maxim Orlov.
Attachment
On 05.05.22 17:47, Maxim Orlov wrote: > During work on 64-bit XID patch [1] we found handy to have initdb > options to set initial xid/mxid/mxoff values to arbitrary non default > values. It helps test different scenarios: related to wraparound, > pg_upgrade from 32-bit XID to 64-bit XID, etc. > > We realize, this patch can be singled out as an independent patch from > the whole patchset in [1] and be useful irrespective of 64-bit XID in > cases of testing of wraparound and so on. > > In particular, we employed this patch to test recent changes in logical > replication of subxacts [2] and found no problems in it near the point > of publisher wraparound. Just for completeness, over in the other thread the feedback was that this functionality is better put into pg_resetwal.
On Fri, 25 Nov 2022 at 07:22, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > > Just for completeness, over in the other thread the feedback was that > this functionality is better put into pg_resetwal. So is that other thread tracked in a different commitfest entry and this one completely redundant? I'll mark it Rejected then? -- Gregory Stark As Commitfest Manager
On Mon, 20 Mar 2023 at 22:31, Gregory Stark (as CFM) <stark.cfm@gmail.com> wrote:
So is that other thread tracked in a different commitfest entry and
this one completely redundant? I'll mark it Rejected then?
Yep, it appears so.
--
Best regards,
Maxim Orlov.