rocicorp · 0xcadams · Jul 15, 2026
diff --git a/.releases/1.9/commits.md b/.releases/1.9/commits.md
diff --git a/assets/search-index.json b/assets/search-index.json
diff --git a/contents/docs/connecting-to-postgres.mdx b/contents/docs/connecting-to-postgres.mdx
@@ -57,6 +57,18 @@ After your server restarts, show the `wal_level` again to ensure it has changed:
 psql -c 'SHOW wal_level'
 ```
 
+### Socket Inactivity Timeout
+
+`zero-cache` monitors wire activity on its Postgres connections so it can recover when a proxy or network failure leaves a half-open socket. The watchdog samples each connection every 120,000 milliseconds by default and resets it after one to two intervals without any bytes read or written. In-flight queries on a reset connection are rejected and can recover through their normal retry or restart paths.
+
+Wire activity resets the watchdog, so streaming operations such as `COPY` remain active. A statement that legitimately computes without sending any data for several minutes can be interrupted. Set `ZERO_PG_SOCKET_INACTIVITY_TIMEOUT` to a longer sampling interval in milliseconds when running such statements:
+
+```bash
+ZERO_PG_SOCKET_INACTIVITY_TIMEOUT=600000
+```
+
+Set the value to `0` to disable the watchdog.
+
 ### Bounding WAL Size
 
 For development databases, you can set a `max_slot_wal_keep_size` value in Postgres. This will help limit the amount of WAL kept around.

diff --git a/contents/docs/otel.mdx b/contents/docs/otel.mdx
diff --git a/contents/docs/release-notes/1.9.mdx b/contents/docs/release-notes/1.9.mdx
@@ -0,0 +1,44 @@
+---
+title: Zero 1.9
+description: Query Correctness and Reliability
+---
+
+## Installation
+
+```bash
+npm install @rocicorp/zero@1.9
+```
+
+You can use `zero-cache` from Docker Hub or GHCR:
+
+```bash
+docker pull rocicorp/zero:1.9.0
+# or
+docker pull ghcr.io/rocicorp/zero:1.9.0
+```
+
+## Overview
+
+Zero 1.9 improves query correctness and `zero-cache` reliability.
+
+## Performance
+
+Deferred.
+
+## Fixes
+
+- [Ordered queries now paginate and maintain windows correctly when cursor fields contain `NULL`, including compound tie-break fields and reverse walks.](https://github.com/rocicorp/mono/pull/6121) This prevents skipped rows, empty windows, and related `Bound should be set` failures. (thanks [@YevheniiKotyrlo](https://github.com/YevheniiKotyrlo)!)
+- [Schema construction, CRUD mutators, and materialized views now preserve a key named `__proto__` as user data instead of invoking JavaScript's legacy prototype setter.](https://github.com/rocicorp/mono/pull/6185) (thanks [@tjenkinson](https://github.com/tjenkinson)!)
+- [Clients now receive changed rows after a server-side query is rebuilt, instead of retaining stale results in a rare rehydration case.](https://github.com/rocicorp/mono/pull/6196)
+- [`zero-cache` now bounds its SQLite prepared-statement caches with LRU eviction, preventing unbounded statement retention when applications generate many distinct query shapes.](https://github.com/rocicorp/mono/pull/6202)
+- [Replication lag reports now retry when an expected report is missing](https://github.com/rocicorp/mono/pull/6187), and [serving-lag metrics exclude disconnected or not-yet-validated client groups](https://github.com/rocicorp/mono/pull/6219). See the updated [OpenTelemetry metric descriptions](/docs/otel#zeroreplication).
+- [`zero-cache` now detects and resets PostgreSQL connections that stop carrying wire traffic](https://github.com/rocicorp/mono/pull/6220), [including over TLS](https://github.com/rocicorp/mono/pull/6221), allowing work to recover from proxy-created half-open sockets. See [Breaking Changes](#postgresql-socket-inactivity-timeout).
+- [`zero-cache` now releases custom-query caches when client groups stop, preventing inactive groups from retaining timers and transformed queries.](https://github.com/rocicorp/mono/pull/6228)
+
+## Breaking Changes
+
+### PostgreSQL Socket Inactivity Timeout
+
+`zero-cache` now monitors wire activity on its PostgreSQL connections. By default, it checks every two minutes and resets a connection after one to two inactive intervals. This recovers half-open connections, but can interrupt a long-running statement that legitimately produces no network traffic.
+
+If legitimate Postgres operations can remain silent for this long, set [`ZERO_PG_SOCKET_INACTIVITY_TIMEOUT`](/docs/connecting-to-postgres#socket-inactivity-timeout) on `zero-cache` to a longer interval in milliseconds. Set it to `0` to disable the watchdog.
diff --git a/contents/docs/release-notes/index.mdx b/contents/docs/release-notes/index.mdx
@@ -2,6 +2,7 @@
 title: Release Notes
 ---
 
+- [Zero 1.9: Query Correctness and Reliability](/docs/release-notes/1.9)
 - [Zero 1.8: Observability and Reliability](/docs/release-notes/1.8)
 - [Zero 1.7: Query Correctness and Performance](/docs/release-notes/1.7)
 - [Zero 1.6: PlanetScale Failover Support](/docs/release-notes/1.6)

diff --git a/contents/docs/zero-cache-config.mdx b/contents/docs/zero-cache-config.mdx
@@ -545,7 +545,7 @@ default: `60000`
 
 ### PG Replication Slot Failover
 
-For upstream Postgres 17+, creates replication slots with the `failover` flag enabled so they can be synchronized to a standby and survive a failover. This requires additional Postgres-side configuration on your provider; see [High Availability and Failover](/docs/connecting-to-postgres#high-availability-and-failover). Has no effect on Postgres versions before 17.
+For upstream Postgres 17+, creates replication slots with the `failover` flag enabled so they can be synchronized to a standby and survive a failover. This requires additional Postgres-side configuration on your provider; see [High Availability](/docs/connecting-to-postgres#high-availability). Has no effect on Postgres versions before 17.
 
 flag: `--upstream-pg-replication-slot-failover`<br/>
 env: `ZERO_UPSTREAM_PG_REPLICATION_SLOT_FAILOVER`<br/>
@@ -651,7 +651,7 @@ env: `ZERO_REPLICA_VACUUM_INTERVAL_HOURS`<br/>
 
 ### Replication Lag Report Interval (ms)
 
-The minimum interval at which replication lag reports are written upstream and reported via the `zero.replication.total_lag` [OpenTelemetry metric](/docs/otel). Because replication lag reports are only issued after the previous one was received, the actual interval between reports may be longer when there is a backlog in the replication stream.
+The minimum interval at which replication lag reports are written upstream and reported via the `zero.replication.total_lag` [OpenTelemetry metric](/docs/otel). If an expected report is not received before the next interval, Zero emits a new report and increments `zero.replication.lag_report_retries`.
 
 This feature requires write access to upstream Postgres (uses `pg_logical_emit_message()`). For PostgreSQL 17+, lag measurements accurately reflect committed write latency (single-digit milliseconds). For PostgreSQL 16 and earlier, measurements may appear 50-100ms longer due to flush behavior. A negative or 0 value disables lag reporting.