fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only (1.1 line) #10

2026-11-10T15:25:06Z

james.maes commented

2026-11-10 15:25:06 +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 66f10bc2384aefbb90222c5b6f11057b2d651ace, a cherry-pick of 77c95b1f627be0613c4fb02195d032d329c1250f (released as 1.0.1) onto release/1.1; the same four files with the same content.

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): BUILD SUCCESS on the first run, 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. No gate was skipped.
Hosted: run 7350 on this commit succeeded on the first attempt (mvn -T1C verify, 536 tests, 0 failures, 0 errors).

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

Merging this pull request pushes to release/1.1, and that push publishes by itself. release/1.1 uses KofTwentyTwo/ci-workflows/.gitea/workflows/maven.yaml@v1; the committed <revision> is 1.1.0-RC.1, so the workflow sets 1.1.0-RC.2, runs mvn -T1C deploy to the QRun-IO Gitea Maven registry, commits Bump version to 1.1.0-RC.2 [skip ci] back to release/1.1 and creates the tag v1.1.0-RC.2. This is read from the workflow; 1.1.0-RC.1 was published the same way by run 7034.

Compared with 1.1.0-RC.1 this adds only this commit. Compared with 1.0.1 the Java classes are the same; the differences are the dependency versions release/1.1 already carries (QQQ 4.1.0-RC.26, Record Files 0.4.0-RC.1, Printing 1.2.0-RC.1, Scripting 1.1.0-RC.3, build parent 2.2.1).

🤖 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 `66f10bc2384aefbb90222c5b6f11057b2d651ace`, a cherry-pick of `77c95b1f627be0613c4fb02195d032d329c1250f` (released as 1.0.1) onto `release/1.1`; the same four files with the same content. - 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): BUILD SUCCESS on the first run, 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. No gate was skipped. - Hosted: run 7350 on this commit succeeded on the first attempt (`mvn -T1C verify`, 536 tests, 0 failures, 0 errors). ## 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 Merging this pull request pushes to `release/1.1`, and that push publishes by itself. `release/1.1` uses `KofTwentyTwo/ci-workflows/.gitea/workflows/maven.yaml@v1`; the committed `<revision>` is `1.1.0-RC.1`, so the workflow sets `1.1.0-RC.2`, runs `mvn -T1C deploy` to the QRun-IO Gitea Maven registry, commits `Bump version to 1.1.0-RC.2 [skip ci]` back to `release/1.1` and creates the tag `v1.1.0-RC.2`. This is read from the workflow; `1.1.0-RC.1` was published the same way by run 7034. Compared with `1.1.0-RC.1` this adds only this commit. Compared with `1.0.1` the Java classes are the same; the differences are the dependency versions `release/1.1` already carries (QQQ `4.1.0-RC.26`, Record Files `0.4.0-RC.1`, Printing `1.2.0-RC.1`, Scripting `1.1.0-RC.3`, build parent `2.2.1`). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 1 commit 2026-11-10 15:25:07 +00:00

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

maven / build (push) Successful in 13m48s

Details

build / maven (push) Successful in 13m48s

Details

66f10bc238

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 e292a14819 into release/1.1

2026-11-10 15:40:16 +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#10