Configuration¶
There is very little to configure. Two settings, one compulsory and one you will use only during a restore.
shared_preload_libraries¶
Compulsory. Covered in Installation, repeated here because it is the setting that matters:
Requires a restart. Required on every server that will open a vault table, including standbys.
Without it, vault tables cannot be opened at all — not even read.
pg_vault_tables.restore_mode¶
Off by default, and should stay off except during a restore.
Superuser only. Session-level, not something to put in postgresql.conf.
While it is off, the retention deadline on a row is always calculated fresh at insert time, and any value supplied by the client is discarded. That is what stops anyone backdating a row to make it deletable.
While it is on, a supplied deadline is kept. That is what a restore needs, so the rows come back with the deadlines they had rather than new ones.
Get this wrong and the restore still succeeds — it just resets every retention clock. See Backups and Restores, which is the only place you should ever need this setting.
Logging¶
No special configuration is needed, but the extension's violation records are written at LOG level to the server log, so they follow your ordinary logging setup.
If you use the logging collector, they go wherever log_directory points. If you ship logs elsewhere, they will be picked up like any other line. They are single lines with a fixed prefix, so they are straightforward to match:
What there is no setting for¶
Worth stating plainly, because people look for these:
- There is no way to disable enforcement. Not per-session, not per-role, not with a GUC.
- There is no maintenance mode that lets you edit a vault table just this once.
- There is no bypass for superusers.
If there were, the guarantee would be worth nothing. The only way to change what a vault table permits is to create a different table.