Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> > But let's assume it makes sense - is this really the right solution? I
> > think what I'd prefer is encryption + rotation of the keys. Which should
> > work properly even on COW filesystems, the performance impact is kinda
> > low and amortized etc. Of course, we're discussing built-in encryption
> > for quite a bit of time.
>
> Yeah, it seems to me that encrypted storage would solve strictly more
> cases than this proposal does, and it has fewer foot-guns.
I still view that as strictly a different solution and one that
certainly won't fit in all cases, not to mention that it's a great deal
more complicated and we're certainly no where near close to having it.
> One foot-gun that had been vaguely bothering me yesterday, but the point
> didn't quite crystallize till just now, is that the only place that we
> could implement such file zeroing is post-commit in a transaction that
> has done DROP TABLE or TRUNCATE. Of course post-commit is an absolutely
> horrid place to be doing anything that could fail, since there's no very
> good way to recover from an error. It's an even worse place to be doing
> anything that could take a long time --- if the user loses patience and
> kills the session, now your problems are multiplied.
This is presuming that we make this feature something that can be run in
a transaction and rolled back. I don't think there's been any specific
expression that there is such a requirement, and you bring up good
points that show why providing that functionality would be particularly
challenging, but that isn't really an argument against this feature in
general.
Thanks,
Stephen
