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

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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 22:22:00
Message-ID: CALj2ACWgpn_aWzzagrerFqD0p1kQv_iioWyJB5R8Cu8j3_yqdA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Sep 15, 2026 at 12:59 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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.

Firstly, thanks for fixing the thinkos in 0d34736e4c1. I will be more
careful and try to catch these next time.

Secondly, as far as these 3 patches are concerned, feel free to ignore
0003 for sure, as 0002 now pretty much covers what I wanted to say for
pg_dump and pg_restore. 0002 is something I agree we need to have. For
0001, I'm not sure the proposed fix is the best option we have here,
and I haven't read the other patches or thoughts on this problem yet.
But I do think the behavior needs to be addressed somehow, because
resetting the reloption is something one can easily do and later run
into issues or miss them entirely. Maybe just documenting it in 0002's
new section is simple enough, asking users to set the reloption back
correctly before running pg_dump.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-09-15 22:28:00 Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Previous Message Daniel Gustafsson 2026-09-15 21:24:54 Re: POC: Carefully exposing information without authentication