| 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-15 07:59:05 |
| Message-ID: | aqj6yd7ztQldv4Tu@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 14, 2026 at 04:43:44PM -0700, Bharath Rupireddy wrote:
> I think I found an issue related to pg_dump/pg_restore where a dump
> and restore after an ALTER TABLE RESET on the reloption would
> downgrade the TOAST table from oid8 back to oid. More details in the
> attached 0001 patch.
I am not convinced by this argument. To me, applying the value set in
the reloption at the moment of the dump and not the chunk_id type
feels like a natural thing to do. We still have time to decide which
behavior makes more sense for this release, but choosing what the
reloption holds at the time of the dump is a property I'd prefer keep.
> I also attached some more patches that I think would help with the
> overall pg_dump and pg_restore along with the migration path for
> existing oid TOAST tables.
>
> I used the nocfbot prefix for these patches to not come in the way of
> the main patches, and they can go after them. Please find them
> attached.
>
> 0001 - fixes the pg_dump/pg_restore downgrade issue
> 0002 - adds a doc section on the migration
> 0003 - adds tests for the oid to oid8 migration and vice versa
0002 seems perhaps like something we should do, but it's independent
of 0001, no? Not sure that the tests of 0003 are really needed. That
feels like bloat compared to the rest already in place.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-09-15 08:00:36 | Re: FIX: BUG #19687: ALTER SEQUENCE missing lock |
| Previous Message | Ashutosh Bapat | 2026-09-15 07:17:48 | Re: PGQ catalog representation and pg_dump support |