Re: Support for 8-byte TOAST values, round two - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for 8-byte TOAST values, round two
Date
Msg-id aqSPIxSTkgb3GTOQ@paquier.xyz
Whole thread
In response to Re: Support for 8-byte TOAST values, round two  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: doc: clarify wal_sender_shutdown_timeout behavior for small values
List pgsql-hackers
On Sat, Sep 12, 2026 at 01:38:06AM +0800, Rui Zhao wrote:
> v17 applies to master (6a1c1102c4), builds warning-free, and make
> check-world passes here.  Three small patches attached: 0001 applies to
> master, 0002 and 0003 on top of 0005.

Thanks for looking and testing.

0001 and 0002 sound like good ideas in terms of coverage, why not, but
I don't really buy the benefit offered by 0003 (see below for reason).

> Rare case: pg_control lost, cluster brought back with pg_resetwal -f as
> documented, the OID counter comes back as the guess, 10000.  On a fresh
> cluster with 1000 values in an oid8 table (chunk_ids 16394 to 17393) and
> 1000 in an oid table, the oid table takes new rows as before and inserts
> into the oid8 table fail with

If you have "lost" a control file, an oid8 value in the past is the
least of your worries.  At least this can be safely be set: just move
it to something like (UINT64_MAX / N) and you should be good enough, N
being a natural integer of your choice.  I still don't buy that adding
a re-check of the value in the TOAST insert path is worth the cost of
this case.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Temporal fkey bugs
Next
From: Michael Paquier
Date:
Subject: Re: Add a permission check to pg_stat_get_backend_subxact()