Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I don't think "commit is atomic" really implies "data should be released
> at commit". This is precisely what makes the feature extremely hard to
> implement, IMHO.
> Why wouldn't it be acceptable to do something like this?
> BEGIN;
> ...
> DROP TABLE x ERASE;
> ...
> COMMIT; <-- Don't do data erasure, just add "x" to queue.
> -- wait for another process to complete the erasure
> SELECT pg_wait_for_erasure();
> That means we're not running any custom commands / code during commit,
> which should (hopefully) make it easier to handle errors.
Yeah, adding actions-that-could-fail to commit is a very hard sell,
so something like this API would probably have a better chance.
However ... the whole concept of erasure being a committable action
seems basically misguided from here. Consider this scenario:
begin;
create table full_o_secrets (...);
... manipulate secret data in full_o_secrets ...
drop table full_o_secrets erase;
... do something that unintentionally fails, causing xact abort ...
commit;
Now what? Your secret data is all over the disk and you have *no*
recourse to get rid of it; that's true even at a very low level,
because we unlinked the file when rolling back the transaction.
If the error occurred before getting to "drop table full_o_secrets
erase" then there isn't even any way in principle for the server
to know that you might not be happy about leaving that data lying
around.
And I haven't even spoken of copies that may exist in WAL, or
have been propagated to standby servers by now.
I have no idea what an actual solution that accounted for those
problems would look like. But as presented, this is a toy feature
offering no real security gain, if you ask me.
regards, tom lane
