fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only (1.0 patch) #8

2026-11-10T02:26:31Z

james.maes commented

2026-11-10 02:26:31 +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 77c95b1f627be0613c4fb02195d032d329c1250f.

Local, ./mvnw -B verify on the whole reactor (Maven 3.9.11 from the wrapper, Java 21, Docker for the MySQL 8.4 and PostgreSQL 17 fixtures, dependencies resolved into an empty local repository from the QRun-IO registry and Maven Central): BUILD SUCCESS, 536 tests, 0 failures, 0 errors, 0 skipped (foundation 234, OpenHTML 15, renderer 174, renderer bridge 52, remote transport 19, record files 19, printing 16, scripting 7). Checkstyle reported 0 violations in every module that runs it, and the foundation coverage check was met.
That was the second local run. The first run stopped in foundation with 1 error in 234 tests: MySqlGenerationQueueTest.freshLockedReadAndPhysicalPoolIsolationRestoration, Communications link failure while the fixture opened a MySQL connection. It did not recur. This change does not touch the MySQL path.
PostgresGenerationQueueTest alone: 29 tests, 0 failures, 0 errors (27 before this change).
Hosted: run 7336 on this commit succeeded (mvn -T1C verify).
Run 7335 on the unchanged base commit 98eef61 (support/1.0) failed at the same time in the existing test PostgresGenerationQueueTest.serverRestartPreservesQueueAndIndependentAudit (FATAL: the database system is not yet accepting connections after the fixture restart), which then failed the two tests after it in their setup. Three runs had been started on the runners at the same moment. Re-run on its own (attempt 2), run 7335 succeeded. That test is not changed here.
System Maven 3.10.0 cannot read this project at this commit (Invalid Artifact Requests: com.kingsrook:qbit-build-parent:pom:${revision}), with or without this change; the wrapper's 3.9.11 is the version the hosted workflow image uses.

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 branch is the v1.0.0 commit plus this one commit, so a v1.0.1 tag on the merge commit publishes 1.0.0 plus this fix and nothing else. The same change for develop is in a separate pull request.

🤖 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 `77c95b1f627be0613c4fb02195d032d329c1250f`. - Local, `./mvnw -B verify` on the whole reactor (Maven 3.9.11 from the wrapper, Java 21, Docker for the MySQL 8.4 and PostgreSQL 17 fixtures, dependencies resolved into an empty local repository from the QRun-IO registry and Maven Central): BUILD SUCCESS, 536 tests, 0 failures, 0 errors, 0 skipped (foundation 234, OpenHTML 15, renderer 174, renderer bridge 52, remote transport 19, record files 19, printing 16, scripting 7). Checkstyle reported 0 violations in every module that runs it, and the foundation coverage check was met. - That was the second local run. The first run stopped in foundation with 1 error in 234 tests: `MySqlGenerationQueueTest.freshLockedReadAndPhysicalPoolIsolationRestoration`, `Communications link failure` while the fixture opened a MySQL connection. It did not recur. This change does not touch the MySQL path. - `PostgresGenerationQueueTest` alone: 29 tests, 0 failures, 0 errors (27 before this change). - Hosted: run 7336 on this commit succeeded (`mvn -T1C verify`). - Run 7335 on the unchanged base commit `98eef61` (`support/1.0`) failed at the same time in the existing test `PostgresGenerationQueueTest.serverRestartPreservesQueueAndIndependentAudit` (`FATAL: the database system is not yet accepting connections` after the fixture restart), which then failed the two tests after it in their setup. Three runs had been started on the runners at the same moment. Re-run on its own (attempt 2), run 7335 succeeded. That test is not changed here. - System Maven 3.10.0 cannot read this project at this commit (`Invalid Artifact Requests: com.kingsrook:qbit-build-parent:pom:${revision}`), with or without this change; the wrapper's 3.9.11 is the version the hosted workflow image uses. ## 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 branch is the `v1.0.0` commit plus this one commit, so a `v1.0.1` tag on the merge commit publishes 1.0.0 plus this fix and nothing else. The same change for `develop` is in a separate pull request. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

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

maven / build (push) Successful in 10m35s

Details

build / maven (push) Successful in 10m35s

Details

77c95b1f62

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 7648868758 into support/1.0

2026-11-10 13:00:22 +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#8