Postgres: как очистить идентификатор транзакции для анонимности и сокращения данных

Question

Мы используем оценочную платформу, где пользователи могут комментировать определенные вещи. Ключевой особенностью является то, что люди могут комментировать только один раз, и каждый комментарий делается анонимно.

Мы используем Postgres для всех наших данных. Мы хотим сохранить в базе данных флаг о том, что пользователь создал комментарий (чтобы он не мог комментировать снова). В отдельной таблице, но внутри одной транзакции, мы хотим сохранить сам комментарий без какой-либо ссылки на пользователя.

Однако postgres сохраняет идентификатор транзакции каждого кортежа, вставленного в базу данных (xmin системные столбцы ). Так что теперь существует связь между пользователем и его комментарием, которую мы должны избегать!

Возможные (не) решения

• Пылесосить сам по себе непомогите, так как не очищает идентификатор транзакции. См. Блок «Примечание» в разделе «24.1.5. Предотвращение ошибок переноса идентификатора транзакции» в postgres docs .

• Размещение этих вставок в разных транзакциях, на самом деле ничего не решает, поскольку идентификаторы транзакций являются последовательными.

• Мы можем объединять комментарии от нескольких пользователейк одному большому тексту в базе данных с некоторыми разделителями, но поскольку старые версии этого большого текста будут сохраняться postgres по крайней мере до следующего вакуума, это не похоже на полное решение. Кроме того, у нас все еще был бы порядок, когда пользователь добавил свой комментарий, что было бы неплохо также не сохранять.

• Периодически переписывать все кортежи в этих таблицах (фиктивным ОБНОВЛЕНИЕМ для них всех), сопровождаемый вакуумом, вероятно, достаточно стерет «историю вставки», но это также выглядит как грубый взлом.

Есть ли другой способв Postgres, чтобы сделать невозможным восстановить историю вставки таблицы?

Answer 1

Я не думаю, что есть проблема.

В своем комментарии вы пишете, что сохраняете флаг с пользователем (каким именно вы его храните), который отслеживает, какие публикации комментировал пользователь. Чтобы сохранить эту информацию конфиденциальной, вы должны оставить этот флаг закрытым, чтобы никто, кроме самого пользователя, не мог прочитать ее.

Если никакой другой пользователь не может видеть эту информацию, то никакой другой пользователь не может видеть xmin насоответствующие записи в таблице. Тогда никто не мог бы сделать корреляцию с xmin в комментарии, поэтому проблема не в этом.

Сложная часть заключается в том, как вы хотите сохранить конфиденциальность информации, которую публикует пользователь, прокомментировал ее. Я вижу два пути:

1. Не используйте для этого методы базы данных, а пишите приложение так, чтобы оно скрывало эту информацию от пользователей.

2. Для этого используйте PostgreSQL Row Level Security.

Нет способа сохранить информацию от суперпользователя. Даже не пытайся.

Answer 2

Вы можете хранить пользователей с их флагами и комментариями в разных кластерах базы данных (и использовать распределенные транзакции), тогда xmin s не будут связаны.

Обязательно отключите track_commit_timestamp.

Чтобы сделать невозможным корреляцию транзакций в базах данных, вы можете выдавать случайные

SELECT txid_current();

, которые ничего не делают, кроме как увеличивают счетчик транзакций.

Answer 3

Возможно, вы могли бы использовать что-то вроде dblink или postgres_fdw для записи в таблицы с использованием удаленного соединения (либо с текущей базой данных, либо с другой базой данных) и тем самым отделитьxmin значений, даже если вы, как пользователь, думаете, что делаете все это в «одной и той же транзакции».

Что касается проблем отслеживания с помощью последовательных обратных значений xmin, поскольку dblink является асинхронным, эта проблемаможет стать спорным в масштабе, когда много пользователей одновременно добавляют комментарии в систему. Это может не сработать, если вам необходимо иметь возможность выполнить откат после обнаружения ошибки - это действительно зависит от того, насколько важно ограничить операции одной транзакцией.