Tested platforms¶
The complete test suite — regression, isolation and TAP — runs on every platform below.
The full matrix is triggered by a build tag, and a release tag runs the primary target. A release is therefore cut from a commit whose full-matrix run has passed, rather than the release tag itself re-running all of it.
PostgreSQL versions¶
| Version | Status |
|---|---|
| 18 | Supported, and the primary target |
| 17 | Tested every release |
| 16 | Tested every release |
| 15 and earlier | Not supported |
The extension is built from a single set of sources with no version-specific code down to PostgreSQL 16.
16 is a committed floor, not a convenience. It is where the table access method API itself changes — tuple_update's last argument became TU_UpdateIndexes * in that release — so it is the oldest major the wrapper design can reach without version-conditional code. Support for it is not contingent on 16 remaining convenient to test: it will not be dropped while PostgreSQL itself supports it.
Operating systems¶
Tested against PostgreSQL 18 on:
| Distribution | Compiler |
|---|---|
| Rocky Linux 8 | gcc 8 |
| Rocky Linux 9 | gcc 11 |
| Debian 12 | gcc 12 |
| Ubuntu 22.04 LTS | gcc 11 |
| Ubuntu 24.04 LTS | gcc 13 |
| Ubuntu 26.04 LTS | gcc 15 |
| Fedora 44 | gcc 15 |
PostgreSQL 16, 17 and 18 are each tested on both Ubuntu 24.04 and 26.04.
The spread of compilers is deliberate. The build treats new warnings as failures, and no single platform surfaces the whole set — Rocky 8's gcc 8 and Fedora's gcc 15 disagree about plenty.
Ubuntu 20.04¶
Not supported. The PostgreSQL project has removed Ubuntu 20.04 from its APT repository entirely, so there are no PostgreSQL 18 packages for it at all. The oldest Ubuntu the PGDG repository still carries is 22.04.
Running it on 20.04 would mean building PostgreSQL itself from source, which is outside what this extension can support.
Architectures¶
Tested on x86-64. The extension contains nothing architecture-specific, but ARM builds are not currently part of the test matrix.
What "tested" means here¶
Each platform runs the full suite:
- Regression tests covering enforcement, retention, the purge routine, transparency to ordinary PostgreSQL, definition integrity, and an adversarial matrix that attempts every forbidden operation as the table owner, as an unprivileged role, and as a superuser.
- Isolation tests for concurrent behaviour, in particular that two transactions racing to make the first insert into an
insertoncetable produce exactly one winner. - TAP tests for dump and restore, physical and logical replication, behaviour when the library is not loaded, the completeness of violation records, and definition integrity under two-phase commit.
The suite is the deliverable rather than a check on it. Every enforcement rule this documentation describes has a test that attempts to break it, including as superuser.
Not interfering with ordinary PostgreSQL¶
The extension's hooks sit on paths every object in the cluster travels, so a separate part of the suite exists to show they change nothing for tables that are not vault tables.
A set of regression files runs last, in its own schemas, using no vault tables at all: every CREATE TABLE and ALTER TABLE form, partitioning, inheritance, foreign keys, maintenance, the full range of ordinary data operations, every object type PostgreSQL offers, and the same again as an unprivileged role.
Those files show ordinary SQL still works. Showing it is unchanged takes a comparison, and there are two:
-
Against a server without the extension. Two clusters are built from the same binaries, differing only in whether the library is preloaded, and given the identical scripts. The output must match byte for byte — once with no vault tables present, and once with them live alongside. Query plans are compared the same way, which answers whether installing this extension changes the plan chosen for an ordinary query.
-
Against PostgreSQL's own regression suite. Core's complete suite — 220 files on PostgreSQL 16, 224 on 17 and 231 on 18 — is run twice on each supported major against clusters identical but for
shared_preload_libraries, and every result file must match.
For the second, identity between the two runs is the assertion, not "core's suite passes". A core test can fail for reasons that have nothing to do with this extension, and requiring identity asks the question that matters while staying immune to the rest.
What this supports is a precise claim rather than a sweeping one: PostgreSQL's own regression suite behaves identically with the library preloaded, and every statement class this project's suite exercises produces byte-identical output with and without it. No test suite enumerates the whole of PostgreSQL, and this documentation does not claim one does.