From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: vacuumdb --missing-stats-only and permission issue |
Date: | 2025-08-21 23:27:23 |
Message-ID: | CADkLM=cXLUyr+2bO+ZkhV=U=Wc1GOgceaRp2CSMd0wvza-ow6g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Unfortunately, pg_stats_ext is also different. The data for that view is
> restricted to table owners (or roles that inherit privileges of the table
> owner).
Ok, I took the RLS and permissions quals from pg_stats and pg_stats_ext
and put them in the corresponding EXISTs tests. The queries could be
written a bit more succinctly (ex. we only need to do the RLS checks once)
but putting them in each EXISTS clause drives home the point that we're
duplicating the filters in pg_stats/pg_stats_ext.
So now, we avoid probing attributes for stats that we know were going to be
filtered out, likewise for extended statistics objects.
The queries don't consult pg_stats_exprs because that's just exposing
different stats from the same pg_statistic_ext_data row, and we already
know that the row is there or not.
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Have-missing-stats-query-use-security-barrier-vie.patch | text/x-patch | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2025-08-21 23:38:33 | Re: Redesigning postmaster death handling |
Previous Message | Matheus Alcantara | 2025-08-21 23:14:47 | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |