Re: Support for 8-byte TOAST values, round two

Hi,

On Wed, Sep 16, 2026 at 4:50 PM Michael Paquier <michael(at)paquier(dot)xyz> 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