Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 15 Jan 2026 18:33:59 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Extended Statistics set/restore/clear functions.
Message-ID: <aWi0hyg8s-bA3SYA@paquier.xyz>
References: <aTYpGfoSuRGTjJnG@paquier.xyz>
 <CADkLM=cFrhE76jnqPZz4pBjyA97qfYkDqWUpw1PK7HEfWB+H4w@mail.gmail.com>
 <CADkLM=dNUxRonk5KUaUpnq-QoiwcoptZKMzqxMLOD=z4NeCZkw@mail.gmail.com>
 <aUzYfkMELU5X1tFk@paquier.xyz>
 <CAHewXNmV6odpdLNYeSaU3RDwzzC5ndbMw2mxuXX74c+8PReYrQ@mail.gmail.com>
 <CAHewXNku-jz-FPKeJVk25fZ1pV2buYh5vpeqGDOB=bFQhKxXhw@mail.gmail.com>
 <aU2_GiTD3dXmxN1c@paquier.xyz>
 <CADkLM=eKxxhXeYsHH7fbLf1waTdAyKeH+A=n039c8Ht+O7JKbA@mail.gmail.com>
 <aWigpNk8CsZtn-P7@paquier.xyz>
 <CADkLM=c1ZGvcu1k0J=Qi+2jvTakQthTdMRvQvETpPTWLPMQSJg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="YYS7kEwlPIpOZeHu"
Content-Disposition: inline
In-Reply-To: <CADkLM=c1ZGvcu1k0J=Qi+2jvTakQthTdMRvQvETpPTWLPMQSJg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aWi0hyg8s-bA3SYA%40paquier.xyz>
Precedence: bulk


--YYS7kEwlPIpOZeHu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 15, 2026 at 03:59:27AM -0500, Corey Huinker wrote:
> Correct, that was done in the v7 patchset to conform to 688dc6299a5b.
>=20
> All four names are available through pg_stats_ext, so the additional
> requirements for pg_dump may not be a an issue. However, I do have some
> vague memory that all four names was a problem in some way beyond just
> giving the parameters more chances to disagree with reality. We'll find o=
ut
> soon enough...

I don't see how providing the four arguments would be an incorrect
thing to do.  We must do the Rangevar lookup first anyway and ensure
that a lock is taken on the relation before opening the catalog.  Or
we would do the opposite of what VACUUM does when updating the stats.
That would also be the opposite of what we do for the relation and
attribute stats.

As you say, these calls will be integrated in pg_dump and pg_upgrade,
but I want these to be right from the start for cases where these
functions are called outside these contexts, like the other
clear/restore functions.  Perhaps that could be made lighter, but at
least what I have sent has a safe ordering, and we would rely on a
single path for the table lookup and the ACL checks.  The key point to
me is that one cannot drop an extended stats object while we lock the
table, looking at the table OID from the pg_stats_ext catalog leads to
more complicated code.  FWIW, I had a lot of fun today testing a lot
of concurrent cases to find out that everything I could think of was
actually unsafe without a proper lock taken first on the table, before
touching the stats, with the lock remaining until the transaction that
calls the function and touches the stats commits, releasing the lock.
--
Michael

--YYS7kEwlPIpOZeHu
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmlotIcACgkQnvQgOdby
QH3cGw/+IEB0pzJtgg1D1S0vGVeBHLsajJZZxR2mpiU5jr06YmyyPqyUYGb/llqk
R2PSemsfGHxFhiKt/dhJpMSgnFzqhq6WPq8K+Ff6EddAShjbXO2qAZ52JUPXICIU
cj4R7/2h120crf+3mv/TyieXQeVfRCIVdkIbwlk0Sz9cO52IsebR5TCMTxuFWnEf
PxSMyYGHF3WlhoK+KxbPmctJhY18WibYPKdrh+Qwf/Q6vtP5RaQvmnYFEVEgU3xQ
mlsd2BpP1EMFyvB4LAs4WyOvspNt/RfIkNRTLa8bN72WivxjD+ysydUAY6f6RZoz
29LEu6wL0xOfzasCgSIn3urYTcMoZdbUgASwRlfgY/aJkzfn3rxcLbbtw2cHEUjt
T4p5CskqTXuSGjzK3EzoBsfijDcIY92aY/OpGJ3WBAwftcMR+/xsk/FIAP74g0KF
9evpfmqjaPKOcjPHmkRKKSwRWHjHYQcsB2WC4hv8uaTu4jZmfF/OcTiDDLEEplhV
TfObMPYhutv27ZZPLoESPwCrqIC1zfPOpyRz0KSPYo6cDzaTBfZvURalWuFEsNV/
RUHVKjA95c9nQB+P3aFnJYi4Ho0WD5dL7h6TSXUE1BsOBYolzoZaOyze6qjSMJBi
+QnVqxweAVIcKgrXXD3K1QW8AkG9Aweor1cA5Oukw8lsjSQBvG8=
=vPpm
-----END PGP SIGNATURE-----

--YYS7kEwlPIpOZeHu--