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