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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Greg Burd <greg(at)burd(dot)me>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support for 8-byte TOAST values, round two
Date: 2026-09-16 23:50:34
Message-ID: aqsrSswQHhLoksQa@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-09-16 23:50:59 Re: POC: Carefully exposing information without authentication
Previous Message Nikolay Samokhvalov 2026-09-16 23:24:26 Re: [PG19][PATCH] Make postgres_fdw statistics import atomic