Compare commits

..
Author SHA1 Message Date
CI 48a627c952 Bump version to 1.1.0-RC.2 [skip ci] 2026-11-10 13:08:02 +00:00
james.maes 8f04068371 Merge pull request 'fix(upload-journal): accept Amazon Aurora PostgreSQL (full_page_writes=off) [release/1.1]' (#64) from fix/aurora-full-page-writes-1.1 into release/1.1
maven / build (push) Successful in 7m59s
build / maven (push) Successful in 7m59s
2026-11-10 13:00:13 +00:00
james.maesandClaude Fable 5.2 c6edde7339 fix(upload-journal): accept Amazon Aurora PostgreSQL (full_page_writes=off)
maven / build (push) Successful in 8m26s
build / maven (push) Successful in 8m25s
The PostgreSQL 17 journal qualification refused every call on Amazon Aurora
PostgreSQL, which reports full_page_writes=off and does not expose the
parameter in its cluster parameter group.

- The settings query gains an eleventh column,
  to_regprocedure('aurora_version()') IS NOT NULL, which is true on Aurora,
  false on stock PostgreSQL 17 and never raises.
- full_page_writes=off is accepted only when that column is true. Stock
  PostgreSQL with full_page_writes=off is still refused, and synchronous_commit,
  fsync, recovery, isolation, time zone and lock timeout are unchanged on Aurora.
- The decision is the pure function tornPagesPrevented, covered by an always-on
  unit test. The opt-in real PostgreSQL 17 suite simulates Aurora with a
  function named aurora_version() and full_page_writes=off on the server.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
2026-11-09 20:21:43 -06:00
CI fbccd185df Bump version to 1.1.0-RC.1 [skip ci] 2026-11-06 20:26:33 +00:00
+6 -6
View File
@@ -21,22 +21,22 @@
<!-- Only the published Redis API package is a permitted cross-qbit boundary. -->
<qbit.guardrails.allowedApiPackages>com.kingsrook.qbits.objectstorage.api,com.kingsrook.qbits.email.api,com.kingsrook.qbits.redis.api</qbit.guardrails.allowedApiPackages>
<qbit.guardrails.allowedQbitArtifacts>com.kingsrook.qbits:qbit-object-storage,com.kingsrook.qbits:qbit-email,com.kingsrook.qbits:*-api,com.kingsrook.qbits:qbit-redis</qbit.guardrails.allowedQbitArtifacts>
<revision>1.2.0-SNAPSHOT</revision>
<revision>1.1.0-RC.2</revision>
<maven.compiler.source>21</maven.compiler.source>
<maven.compiler.target>21</maven.compiler.target>
<jacoco.version>0.8.15</jacoco.version>
<!-- qbit-email from Maven Central -->
<qbit-email.version>0.1.0-RC.11</qbit-email.version>
<qbit-email.version>0.1.0-RC.2</qbit-email.version>
<!-- Core RC.22 (QBitMetaDataProducer, VirtualFieldValueProviderInterface, QServiceUnavailableException); BLOCKED until it resolves from Central/the registry in CI. -->
<qqq.version>4.1.0-RC.26</qqq.version>
<qqq.version>4.1.0-RC.22</qqq.version>
<!-- qbit-redis first release candidate of release/0.1 (producer run 5119 did not publish it yet): BLOCKED, verify the published artifact before pushing. -->
<qbit-redis.version>0.2.0-RC.1</qbit-redis.version>
<qbit-redis.version>0.1.0-RC.1</qbit-redis.version>
</properties>
<parent>
<groupId>com.kingsrook</groupId>
<artifactId>qbit-build-parent</artifactId>
<version>2.2.1</version>
<version>2.1.1</version>
</parent>
<groupId>com.kingsrook.qbits</groupId>
@@ -101,7 +101,7 @@
<dependency>
<groupId>com.kingsrook.qbits</groupId>
<artifactId>qbit-object-storage</artifactId>
<version>0.1.0-RC.10</version>
<version>0.1.0-RC.4</version>
</dependency>
<dependency>
<groupId>com.kingsrook.qqq</groupId>