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: John Naylor <johncnaylorls(at)gmail(dot)com>, 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-22 00:07:21
Message-ID: CALj2ACUbeqMR4V0tjddxLtej=NwdqQy=jbyujdzY+SN9mj4hKg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Sep 21, 2026 at 3:53 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> > I also attached the 0001 and 0002 from
> > https://www.postgresql.org/message-id/CALj2ACUmBhBGb%2B4d8SRq9JT\_ZsObCAvY6-10CKgSWX98zdv2DQ%40mail.gmail.com
> > here as 0002 and 0003.
>
> Not feeling much about 0002 at this stage. I don't disagree about the
> fact of documenting something, but one has a few more ways to do it,
> one being a CTAS with a WITH clause. You could also drop the varlena
> attributes from a definition (after having migrated the values),
> VACUUM FULL to drop the existing TOAST and add a new text attribute to
> force the creation of a new TOAST table based on the new type wanted,
> after an ALTER TABLE SET.

Agreed. Since we don't exactly know which option works better for
users, having one thing documented in core tends to be taken as the
recommended approach, which I would like to avoid. So, I'm fine to
withdraw this.

> > In the attached 0003, I fixed an issue with the remote version check
> > and simplified the tests by reusing an existing table whose reloption
> > is already reset, and verifying that the dump reports the original
> > TOAST type. This is good enough to cover the new code without starting
> > a new instance just to test this. I also used a join instead of a
> > per-relation lookup in the query to get the TOAST type, which avoids
> > an extra catalog lookup for every table.
>
> I still don't think much about this part, FWIW. That's just switching
> some semantics to a different one which shows unclear benefits (aka it
> is about what we should do on the dump side if we find a reloption set
> or not, vs what's stored on disk).

Agreed here as well. I expect one does not frequently reset the TOAST
reloption in production, especially after knowing that it doesn't
affect the table once created and has the data. If anyone raises this
later, at least there is evidence in this thread that it was
discussed. They can set the reloption to match the TOAST table
chunk_id type if they wish to. So, I'm fine to withdraw this as well.

Apologies for the noise. Thanks.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-09-22 00:12:30 Re: Add a permission check to pg_stat_get_backend_subxact()
Previous Message shihao zhong 2026-09-21 23:58:56 Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity