public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Corey Huinker <[email protected]>
Cc: Tender Wang <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Extended Statistics set/restore/clear functions.
Date: Thu, 15 Jan 2026 18:33:59 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADkLM=c1ZGvcu1k0J=Qi+2jvTakQthTdMRvQvETpPTWLPMQSJg@mail.gmail.com>
References: <[email protected]>
<CADkLM=cFrhE76jnqPZz4pBjyA97qfYkDqWUpw1PK7HEfWB+H4w@mail.gmail.com>
<CADkLM=dNUxRonk5KUaUpnq-QoiwcoptZKMzqxMLOD=z4NeCZkw@mail.gmail.com>
<[email protected]>
<CAHewXNmV6odpdLNYeSaU3RDwzzC5ndbMw2mxuXX74c+8PReYrQ@mail.gmail.com>
<CAHewXNku-jz-FPKeJVk25fZ1pV2buYh5vpeqGDOB=bFQhKxXhw@mail.gmail.com>
<[email protected]>
<CADkLM=eKxxhXeYsHH7fbLf1waTdAyKeH+A=n039c8Ht+O7JKbA@mail.gmail.com>
<[email protected]>
<CADkLM=c1ZGvcu1k0J=Qi+2jvTakQthTdMRvQvETpPTWLPMQSJg@mail.gmail.com>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Extended Statistics set/restore/clear functions.
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox