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.
>
> 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 out
> 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
