Re: FPW compression leaks information

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: FPW compression leaks information
Дата
Msg-id 20150707153426.GN12131@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: FPW compression leaks information  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: FPW compression leaks information  (Fujii Masao <masao.fujii@gmail.com>)
Re: FPW compression leaks information  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
* Heikki Linnakangas (hlinnaka@iki.fi) wrote:
> On 07/07/2015 04:31 PM, Stephen Frost wrote:
> >The alternative is to have monitoring tools which are running as
> >superuser, which, in my view at least, is far worse.
>
> Or don't enable fpw_compression for tables where the information
> leak is a problem.

My hope would be that we would enable FPW compression by default for
everyone as a nice optimization.  Relegating it to a risky option which
has to be tweaked on a per-table basis, but only for those tables where
you don't mind the risk, makes a nice optimization nearly unusable for
many environments.

> >I'm not following.  If we don't want the information to be available to
> >everyone then we need to limit it, and right now the only way to do that
> >is to restrict it to superuser because we haven't got anything more
> >granular.
> >
> >In other words, it seems like your above response about not wanting this
> >to be available to anyone except superusers is counter to this last
> >sentence where you seem to be saying we should continue to have the
> >information available to everyone and simply document that there's a
> >risk there as in the proposed patch.
>
> I don't think we can or should try to hide the current WAL location.
> At least not until we have a monitoring role separate from
> superuserness.

I'd rather we hide it now, to allow FPW compression to be enabled for
everyone, except those few environments where it ends up making things
worse, and then provide the monitoring role in 9.6 which addresses this
and various other pieces that are currently superuser-only.  We could
wait, but I think we'd end up discouraging people from using the option
because of the caveat and we'd then spend years undoing that in the
future.
Thanks!
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: New functions
Следующее
От: Bruce Momjian
Дата:
Сообщение: Missing latex-longtable value