The oracle runs nightly and on manual dispatch in a postgres:18 job container. The container supplies the same PostgreSQL 18 initdb, postgres, pg_ctl, pg_basebackup, and psql binaries that the local throwaway-cluster path uses. The harness still creates and removes its own primary and standby; it does not borrow the image entrypoint's server.

Measurements were taken on Ubuntu 24.04 on 2026-08-03 with the Docker and PGDG caches initially cold:

This is a nightly audit rather than a push gate. Repeating a fixed-server audit on every source push spends the same PostgreSQL startup and fixture cost, while a nightly run bounds detection to one day and lets a moving postgres:18 tag audit a newly released minor. workflow_dispatch supports immediate checks after a relevant claim change.

An unexpected result exits nonzero, makes the workflow red, and opens one deduplicated PostgreSQL oracle divergence issue containing the pasteable report and run link. Later failures update that issue; recovery comments on and closes it. Four teaching-scale model defaults are explicitly registered and reported as REGISTERED DIVERGENCE. They do not fail the audit; any other difference, or an unexpected match of one of those four, does.

At measurement time the floating image supplied PostgreSQL 18.4 while CLAIM_VALUES.postgresqlVersion named PostgreSQL 18.3. The resulting version difference is intentionally actionable; it is not added to the four model exceptions.

The sentence that this whole scope was implemented was not true when this gap audit began. The unchanged PostgreSQL 18 run made 211 observations: 207 matched, four were registered model divergences, and none were unexpected. A check-name and SQL-path review gave these pre-fix verdicts:

The missing observations are now implemented. WAL filename and offset values are calculated independently from the observed LSN, timeline and segment size, and the measured file must be that exact current segment. The work-memory family now includes work_mem/per-node-hash-allowance, and work_mem/concurrent-backends-multiply requires per-backend temp-file growth. The MVCC family adds visibility-map/index-only-scan-effect, TOAST/inline-read-path, and xmin-horizon/assigned-xid-removal; the existing prepared, logical-slot, and standby-feedback checks now test actual cutoff or tuple-retention behavior. The Machine family executes statements owned by MACHINE_INDEX_WALK and compares the exact seeded {id: 42, balance: 1042} row.

The completed PostgreSQL 18.3 run made 215 observations in 79.26 seconds: 211 matched, four were the existing registered model divergences, and none were unexpected. The changed WAL, work-memory, storage/MVCC, page-layout, and Machine families also made 44 matching observations on PostgreSQL 13.23 in 21.06 seconds and 44 on PostgreSQL 17.9 in 19.18 seconds. The table below is therefore the implemented expansion boundary, not merely the intended one.

PgBouncer was not installed system-wide. On 2026-08-05, the PGDG PgBouncer 1.25.2 package was downloaded and unpacked into a temporary directory, then run against an isolated PostgreSQL 18.3 cluster with default_pool_size = 1. This was a separate manual third-party oracle, not an observation made by the stock PostgreSQL oracle above.

One client ran a query and stayed connected while a second client attempted to use the one-server pool. Session mode kept the server assigned and the second client remained queued. Transaction mode released the server after the first client's autocommit transaction, but retained it while that client sat after a separate BEGIN. Statement mode released after the autocommit query. A separate BEGIN in statement mode returned FATAL, SQLSTATE 08P01, with transaction blocks not allowed in statement pooling mode; PgBouncer then closed that client connection. The PgBouncer log recorded the same closure reason.

The owned mode set and release boundaries remain cited to PgBouncer's official configuration and feature documentation. The exact failure is additionally tied to the tagged PgBouncer 1.25.2 rejection path and is labeled with that verified version in reader-facing copy. Repository tests cover the city model and cross-surface mode-set invariant; this manual spot oracle is not a nightly PgBouncer compatibility matrix.

For this survey, server-checkable means a controlled fixture can obtain a repeatable verdict from stock PostgreSQL 18, with PostgreSQL 13 and 17 used at version boundaries, using shipped client utilities and bundled contrib extensions. It does not include reading PostgreSQL source or documentation, running PgBouncer/WAL-G/pgBackRest/PGlite, benchmarking elapsed time, or checking PGSimCity's TypeScript and browser behavior. Those need a different verifier even when the underlying prose is true.

The existing oracle already owns GUC values and contexts, catalog/view shapes, wait-event names, pg_stat_io projections, Diagnose SQL executability, index attributes, the registered model defaults, and its current MVCC/storage experiments. The items below define the expansion boundary that the oracle now implements.

The rule for future additions is therefore: register a claim with the oracle only when a stock target server can return a stable, exact observation for it. Model calibration, product heuristics, third-party behavior, documentation semantics, and UI/source conventions stay outside even if a server experiment can illustrate them.