fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only #9

2026-11-10T02:26:34Z

james.maes commented

2026-11-10 02:26:34 +00:00

Defect

GenerationPostgres.qualify refuses every Amazon Aurora PostgreSQL server. Aurora always reports full_page_writes = off and has no parameter to change it, because its storage layer does not write torn pages. Measured on an Aurora PostgreSQL 17.9 cluster: synchronous_commit = on, fsync = on, full_page_writes = off (context sighup, source default, absent from the cluster parameter group). The first authoring call in production failed with Generation requires synchronous PostgreSQL commits, full-page writes, ...; not satisfied: synchronous commit.

Change

The settings query returns one more column: to_regprocedure('aurora_version()') IS NOT NULL. It is true on Aurora, false on stock PostgreSQL 17 and never raises an error.
full_page_writes = off is accepted only when that column is true. The decision is one small function, GenerationPostgres.durable(synchronousCommit, fsync, fullPageWrites, aurora).
Unchanged on every server, Aurora included: fsync on, synchronous_commit on or remote_apply, primary and writable, version 17, UTC, READ COMMITTED, bounded lock_timeout, the table checks. Stock PostgreSQL with full_page_writes = off is still refused.
The refusal text now reads full-page writes (except on Amazon Aurora PostgreSQL), because the old text would be wrong on Aurora. The not satisfied: labels are unchanged.
docs/DURABLE-QUEUE.md states the rule in place of "PostgreSQL/Aurora are not implicitly supported".

No schema change. No dependency change. Nothing else is in this pull request.

Tests

PostgresGenerationQueueTest gains two cases.

fullPageWritesOffIsAcceptedOnlyOnAuroraAndNothingElseIsRelaxed runs on a real postgres:17 container started without the durability settings on the command line, so the test can really change them with ALTER SYSTEM and a reload. It checks: stock with full_page_writes off is refused; the same server with an aurora_version() function is accepted and a request generates; with that function, fsync off is refused and synchronous_commit off is refused; after the function is dropped the server is refused again.
durabilityRuleAcceptsOnlyTheAuroraFullPageWritesException checks the decision function for the remaining combinations, with no server.

What is simulated: Aurora itself. A function named aurora_version() is created in the test database so the same to_regprocedure detection resolves. No test in this repository runs on Aurora.

Verification

Commit cfbf0744f9fa1706a7ea5c8bdca43754b2a0d274, a cherry-pick of 77c95b1f627be0613c4fb02195d032d329c1250f (same four files, same content).

Hosted: run 7337, attempt 2, succeeded (mvn -T1C verify). Attempt 1 failed in the existing test PostgresGenerationQueueTest.serverRestartPreservesQueueAndIndependentAudit (FATAL: the database system is not yet accepting connections after the fixture restart), which then failed the three tests after it in their setup, the new Aurora test among them. Three runs had been started on the runners at the same moment, and the run on the unchanged v1.0.0 commit failed the same way. The re-run was tea api -X POST repos/QRun-IO/qbit-document-generation/actions/runs/7337/rerun.
Local: no build of this develop commit was run. The 1.0 commit passed ./mvnw -B verify locally (536 tests, 0 failures, 0 errors, 0 skipped); see pull request 8.

Limit of the detection

to_regprocedure('aurora_version()') resolves through the session search_path. On stock PostgreSQL a role that can create a function in a schema on that path could make the server look like Aurora. That only matters on a server that also runs full_page_writes = off, which needs superuser.

Release

This is the same commit as the 1.0 patch pull request (base support/1.0), cherry-picked onto develop so the next release line keeps the fix. Merging it publishes the next develop SNAPSHOT; it is not the release GG Forge adopts.

🤖 Generated with Claude Code

## Defect `GenerationPostgres.qualify` refuses every Amazon Aurora PostgreSQL server. Aurora always reports `full_page_writes = off` and has no parameter to change it, because its storage layer does not write torn pages. Measured on an Aurora PostgreSQL 17.9 cluster: `synchronous_commit = on`, `fsync = on`, `full_page_writes = off` (context sighup, source default, absent from the cluster parameter group). The first authoring call in production failed with `Generation requires synchronous PostgreSQL commits, full-page writes, ...; not satisfied: synchronous commit`. ## Change - The settings query returns one more column: `to_regprocedure('aurora_version()') IS NOT NULL`. It is true on Aurora, false on stock PostgreSQL 17 and never raises an error. - `full_page_writes = off` is accepted only when that column is true. The decision is one small function, `GenerationPostgres.durable(synchronousCommit, fsync, fullPageWrites, aurora)`. - Unchanged on every server, Aurora included: `fsync` on, `synchronous_commit` on or `remote_apply`, primary and writable, version 17, UTC, READ COMMITTED, bounded `lock_timeout`, the table checks. Stock PostgreSQL with `full_page_writes = off` is still refused. - The refusal text now reads `full-page writes (except on Amazon Aurora PostgreSQL)`, because the old text would be wrong on Aurora. The `not satisfied:` labels are unchanged. - `docs/DURABLE-QUEUE.md` states the rule in place of "PostgreSQL/Aurora are not implicitly supported". No schema change. No dependency change. Nothing else is in this pull request. ## Tests `PostgresGenerationQueueTest` gains two cases. - `fullPageWritesOffIsAcceptedOnlyOnAuroraAndNothingElseIsRelaxed` runs on a real `postgres:17` container started without the durability settings on the command line, so the test can really change them with `ALTER SYSTEM` and a reload. It checks: stock with `full_page_writes` off is refused; the same server with an `aurora_version()` function is accepted and a request generates; with that function, `fsync` off is refused and `synchronous_commit` off is refused; after the function is dropped the server is refused again. - `durabilityRuleAcceptsOnlyTheAuroraFullPageWritesException` checks the decision function for the remaining combinations, with no server. What is simulated: Aurora itself. A function named `aurora_version()` is created in the test database so the same `to_regprocedure` detection resolves. No test in this repository runs on Aurora. ## Verification Commit `cfbf0744f9fa1706a7ea5c8bdca43754b2a0d274`, a cherry-pick of `77c95b1f627be0613c4fb02195d032d329c1250f` (same four files, same content). - Hosted: run 7337, attempt 2, succeeded (`mvn -T1C verify`). Attempt 1 failed in the existing test `PostgresGenerationQueueTest.serverRestartPreservesQueueAndIndependentAudit` (`FATAL: the database system is not yet accepting connections` after the fixture restart), which then failed the three tests after it in their setup, the new Aurora test among them. Three runs had been started on the runners at the same moment, and the run on the unchanged `v1.0.0` commit failed the same way. The re-run was `tea api -X POST repos/QRun-IO/qbit-document-generation/actions/runs/7337/rerun`. - Local: no build of this `develop` commit was run. The 1.0 commit passed `./mvnw -B verify` locally (536 tests, 0 failures, 0 errors, 0 skipped); see pull request 8. ## Limit of the detection `to_regprocedure('aurora_version()')` resolves through the session `search_path`. On stock PostgreSQL a role that can create a function in a schema on that path could make the server look like Aurora. That only matters on a server that also runs `full_page_writes = off`, which needs superuser. ## Release This is the same commit as the 1.0 patch pull request (base `support/1.0`), cherry-picked onto `develop` so the next release line keeps the fix. Merging it publishes the next `develop` SNAPSHOT; it is not the release GG Forge adopts. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 1 commit 2026-11-10 02:26:34 +00:00

fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only

maven / build (push) Successful in 6m14s

Details

build / maven (push) Successful in 6m14s

Details

cfbf0744f9

Generation qualification refused every Amazon Aurora PostgreSQL server:
Aurora always reports full_page_writes = off and has no parameter to change
it, because its storage layer does not write torn pages.

The settings query now also returns
to_regprocedure('aurora_version()') IS NOT NULL (true on Aurora, false on
stock PostgreSQL, never an error). full_page_writes = off is accepted only
when that is true. Stock PostgreSQL must still report it on, and fsync on,
synchronous_commit on or remote_apply and every other check are unchanged
on both. The refusal text now says full-page writes are not required on
Aurora.

Tests run on a real postgres:17 engine whose settings are really changed;
only Aurora is simulated, by creating a function named aurora_version() in
the test database.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

james.maes merged commit 228931a937 into develop

2026-11-10 22:57:57 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-document-generation#9