Re: Multivariate MCV stats can leak data to unprivileged users
От | Tomas Vondra |
---|---|
Тема | Re: Multivariate MCV stats can leak data to unprivileged users |
Дата | |
Msg-id | 20190518232812.qpnjmydlx3uzzsj7@development обсуждение исходный текст |
Ответ на | Re: Multivariate MCV stats can leak data to unprivileged users (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Multivariate MCV stats can leak data to unprivileged users
|
Список | 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
В списке pgsql-hackers по дате отправления: