Re: Multivariate MCV stats can leak data to unprivileged users

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multivariate MCV stats can leak data to unprivileged users
Date: 2019-06-11 06:04:34
Message-ID: CACPNZCvrmNLZ9cHh5voCn8R+RnGJC0axXLPo+ENboH2KJYGCCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 7, 2019 at 4:33 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> 2) 0002 - update sgml docs to reflect changes from 0001

There is some copypasta here in the new section referring to the old catalog:

+ <sect1 id="catalog-pg-statistic-ext-data">
+ <title><structname>pg_statistic_ext_data</structname></title>
+
+ <indexterm zone="catalog-pg-statistic-ext">
+ <primary>pg_statistic_ext</primary>
+ </indexterm>
+
+ <para>
+ The catalog <structname>pg_statistic_ext</structname>
+ holds extended planner statistics.
+ Each row in this catalog corresponds to a <firstterm>statistics
object</firstterm>
+ created with <xref linkend="sql-createstatistics"/>.
+ </para>

And a minor stylistic nit -- it might be good to capitalize "JOIN" and
"ON" in the queries in the docs and tests.

> One thing I think we should fix is naming of the attributes in the 0001
> patch. At the moment both catalogs use "stx" prefix - e.g. "stxkind" is
> in pg_statistic_ext, and "stxmcv" is in pg_statistic_ext_data. We should
> probably switch to "stxd" in the _data catalog. Opinions?

That's probably a good idea.

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-11 06:11:15 check_recovery_target_lsn() does a PG_CATCH without a throw
Previous Message Michael Paquier 2019-06-11 05:56:36 Re: pg_basebackup failure after setting default_table_access_method option