Feedback-ID: i0fe9450f:Fastmail
Date: Sat, 12 Sep 2026 08:30:43 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Rui Zhao <zhaorui126@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Greg Burd <greg@burd.me>, Yugo Nagata <nagata@sraoss.co.jp>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Support for 8-byte TOAST values, round two
Message-ID: <aqSPIxSTkgb3GTOQ@paquier.xyz>
References: 
 <CALj2ACWTM=VgjDU=2BBuYAh2Ae8Kq5NspJZsmhiAvNQkXZ=MjQ@mail.gmail.com>
 <aqCvLyFwAwviycfu@paquier.xyz>
 <4272005a-ca62-46be-aab3-8678187d84cd@app.fastmail.com>
 <e971c02b-3472-4f94-9259-a0c70675206e@app.fastmail.com>
 <aqHpYL-ytLbT3jGR@paquier.xyz>
 <aqJhmsEEiAUKQFXN@paquier.xyz>
 <CALj2ACWEY0HHREE5Dn9Waa33coj-SwxPRkEtW4A=nCSzN8UrAQ@mail.gmail.com>
 <CALj2ACVG9cjxr-0jb8PP_Vb7vJvVGBVM_fQ2srt4CpyURpfYhQ@mail.gmail.com>
 <aqOu0TEpCM_oPksP@paquier.xyz>
 <CAHWVJhGkb1n_QSS4M=PKJD5HHcwK3KXpFwVxoRVLzAG3j+2fhQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="6ntcIi/4o0Bt0tLO"
Content-Disposition: inline
In-Reply-To: 
 <CAHWVJhGkb1n_QSS4M=PKJD5HHcwK3KXpFwVxoRVLzAG3j+2fhQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aqSPIxSTkgb3GTOQ%40paquier.xyz>
Precedence: bulk

--6ntcIi/4o0Bt0tLO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--6ntcIi/4o0Bt0tLO
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmqkjyMACgkQnvQgOdby
QH0IlBAAjmQFZyJwSJuL19gPw6q/xUpAGj+/9LxJ80Z/B+wZPlcJLPAfFqRcViQl
iYi48iWgR3q3Q/l1r9MR1QKRXUGZk+7n1lHPt8oHvVsobYPpTNllx5ogi2iQ+pfv
bEnxhk21P/9ZpVNJX3LJpCayPR3skfpapatu4bDU11h4iQEPbfvcBCeNdlvIYHUW
y1Ll4yN5lqiis8IM8aTdF8P+Ve6TfjQzg4XCp20T9/3bO4Uj/wuhL+zpgl6H5E1b
EzZ8k0S0hdRMZzDlWlH1dwk1TNN1nes/YO5T2dPAfwNH+HoJwa36BlR31CUKwg8X
zlZ2q1aIxK6W6drmc/FAcpofouTJLvUHZJWH+XEJSQFj3QTt8k25sKnWDFV7s656
DoahNWVoQ+JCW+E7J70qfQjTbQsmzJA9g74MP1gX8WcM5rP31cigvOidSoyumFpR
tBu9dvWYJCuj4liCkZ0x7w6ub9K9RKtxts/VPntJS/y9dvTJDgNoPekPdkW6rO3Y
r/92htwdasqGZEdhiJPR2zTIUeARAJsqJRyaaZi20B33eEhFfXUaSZp8Z0kKcDii
8WpFY4hwmyvBuGI/W9NZuGqlLD6PCVRIH7OyrmSXfN4k+bhxsM6d3lp7thuGRYuC
EX5zP7s/2RFc7aZXJMsedS8S7VvNZ9XyqYjGbKPXtSTyminYvgI=
=as3R
-----END PGP SIGNATURE-----

--6ntcIi/4o0Bt0tLO--