Hi!

since 9.4, VACUUM FREEZE just sets a flag bit instead of overwriting xmin with 
FrozenTransactionId [1]. This makes it harder to build applications with a 
focus on data reduction.

We have an app that lets people anonymously vote on stuff exactly once. So we 
save the vote in one table without any explicit connection to the voting user, 
and separate from that a flag that this person gave their vote. That has to 
happen in the same transaction for obvious reasons, but now the xmin of those 
two data points allows to connect them and to de-anonymize the vote.

We can of course obfuscate this connection, but our goal is to not keep this 
data at all to make it impossible to de-anonymize all existing votes even when 
gaining access to the server. The best idea we had so far is more of a 
workaround: Do dummy updates to large parts of the vote table on every insert 
so lots of tuples have the same xmin, and them VACUUMing.[2]

Does anyone have a suggestion better than this? Is there any chance this 
changes anytime soon? Should I post this to -hackers?

Any input would be appreciated!

Johannes


[1] See the blue box on this page: 
https://www.postgresql.org/docs/current/routine-vacuuming.html

[2] The ctid poses a similar problem. We think we have fixed that by making the 
primary key of the vote table a UUID, after which we periodically cluster the 
whole table.



Reply via email to