|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Multivariate MCV stats can leak data to unprivileged users|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>On Sat, 18 May 2019 at 16:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> > On the other hand, pg_dump relies on pg_statistic_ext to work out
>> > which extended statistics objects to dump. If we were to change
>> > to use pg_stats_ext, then a user dumping a table with RLS using the
>> > --enable-row-security flag wouldn't get any extended statistics
>> > objects, which would be a somewhat surprising result.
>> 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. I'd have expected that
>> keeping those in separate catalogs would be the thing to do, though
>> perhaps it's too late for that.
>Yeah, with the benefit of hindsight, that would have made sense, but
>that seems like a pretty big change to be attempting at this stage.
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?
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|Next Message||Tom Lane||2019-05-18 18:55:01||Re: Segfault on ANALYZE in SERIALIZABLE isolation|
|Previous Message||David Fetter||2019-05-18 18:39:08||Re: New EXPLAIN option: ALL|