Re: FPW compression leaks information

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FPW compression leaks information
Date: 2015-07-07 15:34:27
Message-ID: 20150707153426.GN12131@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Heikki Linnakangas (hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-07-07 15:34:35 Missing latex-longtable value
Previous Message Michael Paquier 2015-07-07 15:34:23 Re: New functions