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
signature.asc
Description: PGP signature
