On Wed, Sep 16, 2026 at 10:48:35AM -0700, Bharath Rupireddy wrote:
> While I agree with the general idea that having a way to enforce the
> initial OID after an initdb is a good one, just curious, why is this
> specific to the pg_resetwal being added to the recovery test in
> 006_logical_decoding.pl? Or is the intention to not exercise this test
> always? I'm still not clear on why we need to solve this problem here.
The duplication at SQL level in the TAP tests that all these
pg_resetwal commands create is what drives me toward a more general
solution as being suited. We want to check for UNIT32_MAX overflows
in a general way than just something inside one test. Using a
pg_resetwal command in the pg_upgrade test feels like a good
investment: we run the main regression test suite all the time there.
Instead of a PG_TEST_EXTRA variable another set of ideas one I can
think of out-of-the-box is something that would be based on a compile
flag. For example a development GUC?
Or maybe just a few feature in itself, like an initdb option that
forces an initial OID after bootstrap in the control file? Then link
it to a new PG_TEST_EXTRA mode? Having something that could be
directly used by the buildfarm on an opt-in basis would be kind of
nice.
So, I'd rather have a more general mechanism in place rather than
finishing with 250 pg_resetwal commands sprinkled across the tree that
duplicate SQL tests we have in the script in 10 years.
--
Michael
