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 01:59:26
Message-ID: aqn3_uSBKRlsHCOV@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2026-09-16 02:21:20 SQL/JSON DEFAULT ON ERROR/ON EMPTY evaluation fail should rethrow error unconditionally
Previous Message Xuneng Zhou 2026-09-16 01:28:20 Re: Reject WAIT FOR earlier in transaction-snapshot mode