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

Hi,

On Tue, Sep 15, 2026 at 6:59 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Sep 14, 2026 at 02:00:49PM +0900, Michael Paquier wrote:
> > And rebased is a v18 with the three remaining pieces, plus two more
> > test patches: the tests of Rui with decoding and oid8 values higher
> > than 2^32, and my test to have the main regression test suite of
> > pg_upgrade run with a default oid8 in the control file higher than
> > 2^32, checking that assigned chunk numbers are handled correctly.
>
> While thinking again about v18-0004 and v18-0005 that were the latest
> items on my list, I am having second thoughts about v18-0004 that has
> the idea to plug in one more pg_resetwal call to satisfy *ONE* case,
> while the SQLs of test_decoding are able to do much more than that.
>
> As a whole, it feels like a waste of cycles once we become able to do
> an installcheck on a cluster that has an initial OID set to more than
> UINT32_MAX. The pg_resetwal calls in pg_wal and the TLI recovery test
> still make sense, as they cover specifics for the WAL records and the
> control file. Just that the SQL tests are harder to justify presented
> this way. So how about this wilder idea of a new PG_TEST_EXTRA
> enforcing the initial OID value after an initdb?

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.

Also, the fact that this test is kept at the end of the test file
means it doesn't impact any other test case in the file, though
keeping it at the end in the future could be hard if that's an issue
at all.

That said, I measured the cost that this additional pg_resetwal brings
to the test timings. On a release build on my dev machine (EC2
r7i.8xlarge), over 10 runs of just 006_logical_decoding.pl, the
testing time goes from 1.101s to 1.162s, of which the pg_resetwal
itself is about 29ms. This isn't huge IMO for bigger machines, however
this could be costlier for most of the CF bot, CI and BF animals out
there though.

In short, I don't think we need to worry much about this as part of
this thread. Maybe separately, yes, if the goal is to remove
pg_resetwal across all TAP tests with what you proposed above, that
seems fine to me.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com