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
signature.asc
Description: PGP signature
