"asaba.takan...@fujitsu.com" <asaba.takan...@fujitsu.com> writes: > I want to add the feature to erase data so that it cannot be restored > because it prevents attackers from stealing data from released data area.
I think this is fairly pointless, unfortunately. Dropping or truncating tables is as much as we can do without making unwarranted assumptions about the filesystem's behavior. You say you want to zero out the files first, but what will that accomplish on copy-on-write filesystems? Even granting that zeroing our storage files is worth something, it's not worth much if there are more copies of the data elsewhere. And any well-run database is going to have backups, or standby servers, or both. There's no way for the primary node to force standbys to erase themselves (and it'd be a different sort of security hazard if there were). Also to the point: if your assumption is that an attacker has access to the storage medium at a sufficiently low level that they can examine previously-deleted files, what's stopping them from reading the data *before* it's deleted? So I think doing anything useful in this area is a bit outside Postgres' remit. You'd need to be thinking at an operating-system or hardware level. regards, tom lane