Re: Multivariate MCV stats can leak data to unprivileged users
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Dean Rasheed <dean.a.rasheed@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-05-18T23:28:12Z
Lists: pgsql-hackers
On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote: >Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: >> On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote: >>>> On Sat, 18 May 2019 at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>> It seems like what we need here is to have a separation between the >>>>> *definition* of a stats object (which is what pg_dump needs access >>>>> to) and the current actual *data* in it. > >>> Otoh, having a suboptimal catalog representation that we'll likely have >>> to change in one of the next releases also isn't great. Seems likely >>> that we'll need post beta1 catversion bumps anyway? > >> But that's not an issue intruduced by PG12, it works like that even for >> the extended statistics introduced in PG10. > >Yeah, but no time like the present to fix it if it's wrong ... > Sorry, not sure I understand. Are you saying we should try to rework this before the beta1 release, or that we don't have time to do that? I think we have four options - rework it before beta1, rework it after beta1, rework it in PG13 and leave it as it is now. If the pg_dump thing si the only issue, maybe there's a simple solution that reworking all the catalogs. Not sure. Are there any other reasons why the current catalog representation would be suboptimal, or do we have some precedent of a catalog split this way? I can't think of any. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add security checks to the multivariate MCV estimation code.
- d7f8d26d9f4c 12.0 landed
-
Add pg_stats_ext view for extended statistics
- aa087ec64f70 12.0 landed
-
Rework the pg_statistic_ext catalog
- 6cbfb784c3c9 12.0 landed