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

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