sydtest-persistent-postgresql-0.5.2.0: CHANGELOG.md

# Changelog

## [0.5.2.0] - 2026-09-26

### Fixed

* A read against the standby is no longer destroyed by a vacuum on the
  primary. The standby was configured to serve reads and to stay deliberately
  behind, and then left to postgres' defaults on what should happen when
  recovery met one of those reads: the primary was never told what a standby
  reader was holding, so it was free to remove those row versions, and
  replaying the cleanup cancelled the reader. The read came back as `SQLSTATE
  40001`, or, when the session was holding a snapshot, as a dropped
  connection.

  The standby now sends `hot_standby_feedback`, so the primary keeps what the
  standby's readers still need, and reports it often enough to matter for
  databases that live as briefly as these do. Recovery also waits for a
  conflicting read rather than cancelling it, which covers the conflicts
  feedback does not: a cleanup already in flight, or a lock that replayed DDL
  wants. A replica in a test suite is there to be behind, and a test that
  wants it caught up says so with `awaitReplica`.

## [0.5.1.0] - 2026-09-14

### Changed

* `pg_basebackup` takes its checkpoint immediately rather than spreading it
  out. Starting a standby goes from about 13.5 seconds to about 0.17.

## [0.5.0.0] - 2026-09-13

### Added

* A suite can run against a real PostgreSQL hot standby of the database it
  writes to, so an application that offloads reads onto a read replica can be
  tested on one. `persistPostgresqlReplicatedSpec` is `persistPostgresqlSpec`
  with a replica, and gives each test a `ReplicatedPools`: a pool to a fresh
  database on the primary, and a pool to the same database on the standby.

  The standby is a `pg_basebackup` streaming through a replication slot, held
  behind by `recovery_min_apply_delay` so that being behind is a fact rather
  than a race. It replays the same write-ahead log a production replica does,
  in the same order, and refuses writes because postgres refuses them.

* `onPrimary`, `onReplica` and `awaitReplica` for reaching either end and for
  waiting until the standby has caught up.

* `unreplicatedPools`, for the application that is configured without a
  replica: the same database through both pools, where `awaitReplica` returns
  at once.

* `ReplicaConfig` and `defaultReplicaConfig` for how far behind the replica is
  held, and `persistPostgresqlReplicatedSpecWith` to choose it.

* `persistPostgresqlReplicatedAdminSpec`, `replicatedPoolsSpec`,
  `postgresqlStandbySetupFunc`, `standbyPoolSetupFunc`,
  `replicatedPoolsSetupFunc`, `replicationPrimaryConfig`, `ReplicatedDB` and
  `Standby`, for a suite that needs the standby somewhere else in its resource
  stack.

* `postgresqlServerSetupFuncWith` and `persistPostgresqlAdminSpecWith`, which
  take the `tmp-postgres` configuration from the caller. `tmp-postgres`'
  `defaultConfig` asks for `wal_level = minimal`, which writes too little to
  the log for anything to replay and at which postgres refuses to start with a
  nonzero `max_wal_senders`, so the configuration had to become the caller's to
  choose.

* `testDatabaseSetupFunc`, which is `connectionPoolSetupFunc` plus the
  connection options the pool was opened with. A second connection to the same
  database, which is what the standby pool is, needs to know which database
  that is.

## [0.4.0.0] - 2026-05-17

### Added

* `postgresqlServerSetupFunc`, `postgresqlUserSetupFunc`, and
  `postgresqlDatabaseSetupFunc` are now exported as building blocks
  for composing custom setup chains.
* `emptyPostgresPoolSetupFunc` provides a `ConnectionPool` to a fresh
  empty database (server + user + db + pool) without going through a
  migrated template.

### Changed

* Internal helpers `adminDBSetupFunc`, `tempUserSetupFunc`, and
  `tempNewDatabaseSetupFunc` were renamed to `postgresqlServerSetupFunc`,
  `postgresqlUserSetupFunc`, and `postgresqlDatabaseSetupFunc` and
  promoted to the public API.

## [0.3.0.0] - 2025-12-26

### Changed

* Complete overhaul: Tests now run with their own database based on a template
  database instead of their own entire postgres server.

## [0.2.0.3] - 2023-10-09

### Added

* Compatibility with `GHC >= 9.8`.

## [0.2.0.2] - 2022-05-05

### Added

* `postgresqlMigrationSucceedsSpec`

## [0.2.0.1] - 2022-04-26

### Added

* Compatibility with `GHC >= 9`

## [0.2.0.0] - 2021-06-19

### Added

* Dependency on `sydtest-persistent`

### Changed

* Type of `runSqliteTest` is changed to run `SqlPersistM` instead of `SqlPersistT IO`