Re: vacuumdb --missing-stats-only and permission issue

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

In response to

Browse pgsql-hackers by date

  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