Hi, On Wed, Sep 16, 2026 at 4:50 PM Michael Paquier <[email protected]> wrote: > > 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.
IIUC, the SQL duplication referred to is that the 8-byte TOAST chunk_id tests proposed here repeat the same create table and DMLs that toast.sql already has. I would like to keep things minimal to the core where possible and have the 8-byte TOAST tests run every time across various BF animals (not behind a PG_TEST_EXTRA flag or such). A developer GUC behind a compile-time macro (similar to clobber cache for example) would be a nice option. However, this doesn't meet my requirement of running these tests every time on all BF animals. And I don't think an initdb option is a good idea here, because this is not something one would use in production, just for testing, so -1 on that. Another approach, which I don't recommend, is to have a SQL function that modifies the OID counter directly. I know this is much worse because such a function, even behind a superuser check, is reachable on production systems. No go here, but just saying. That said, if I relax my requirement of running these tests every time on every BF animal a bit, the developer GUC behind a compile-time macro seems like a good idea. Another approach is a new test module in src/test/modules (similar to the xid_wraparound module) with a simple SQL function that advances the OID counter in shared memory, similar to core's SetNextObjectId(). Being a test module, it doesn't impact production systems, and all the 8-byte TOAST chunk_id related tests added for this feature can be moved here and run across all BF animals. Others may have a different opinion. Meanwhile, IMHO, the remaining v18 tests can go in, with this discussed separately. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
