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-14 00:46:12
Message-ID: aqdD1J9SurXForkI@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2026 at 10:07:37AM -0700, Bharath Rupireddy wrote:
> Upon thinking more, I think we need a test case where pg_resetwal sets
> the OID8 counter beyond the OID4 limit of 4 billion and verify that
> the TOAST chunk_id goes beyond that to properly cover the OID8 case.
> The tests added by v17-0004-Add-battery-of-tests-related-oid8.patch,
> although they create a table with OID8 TOAST, all use chunk_ids within
> the OID4 limits.

Yes, Rui has proposed a few things to cross the gap here:
https://www.postgresql.org/message-id/CAHWVJhGkb1n_QSS4M=PKJD5HHcwK3KXpFwVxoRVLzAG3j+2fhQ@mail.gmail.com

One thing that he has done is to check a reorderbuffer change with the
control file holding a value larger than UINT32_MAX. I agree that
having a "normal" SQL case would be adapted, but why not just plug one
SELECT into pg_upgrade once varatt_external_oid8 is introduced? We
hold into toasttest_oid8 and toasttest_oid in patch 0004 for this
purpose. The check cannot be added before 0005, but the basics are
here.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2026-09-14 01:39:34 Re: Support for 8-byte TOAST values, round two
Previous Message Michael Paquier 2026-09-13 23:51:43 Re: Support for 8-byte TOAST values, round two