PG Exporter v1.6.0

PG Exporter v1.6.0 separates health probes from collection, bounds overlapping metrics requests, preserves completed bounded refreshes after client cancellation, and corrects cross-database progress labels. It also supplies container trust roots and updates dependencies. The Go toolchain remains 1.27.3 and the PostgreSQL driver remains lib/pq 1.12.3.

Changes

• Independent health probes: slow metrics collection no longer blocks the background probe. Completing a scrape no longer overwrites a newer reachability or role observation. After initialization, HTTP health is written only by the probe; pg_up and pg_in_recovery remain collection results. A reachable database can return /up HTTP 200 even when a fatal collector makes pg_up zero.
• Controlled overlapping scrapes: at most two metrics requests are admitted, including waiting and response writing. Collection remains serial. The second request can wait and reuse caches; extra requests receive HTTP 503. Waiting can be canceled without starting SQL. The request budget is 30 seconds, shortened by a valid positive finite Prometheus scrape-timeout header.
• Collector-level cancellation: request cancellation prevents the next collector or database from starting. A collector already running with a positive timeout continues its predicates and main SQL under one shared deadline, then caches its result normally. This prevents a departing client from turning a healthy bounded refresh into a failure cached for other scrapers. A negative timeout removes the collector deadline and lets the request cancel its SQL.
• Clearer interruption accounting: interrupted passes have an INFO interrupted summary and do not increment exporter/server scrape-error counts. Availability preserves the previous value, or becomes true after a successful precheck. Non-interrupted connection and fatal collector failures still count. Query-error statistics and fatal-query ERROR logs remain unchanged.
• Correct progress labels: pg_vacuuming, pg_indexing, and pg_clustering retain cluster-wide coverage and three queries per refresh. Relations in the connected database and system catalogs resolve to names; user relations in other databases use numeric OIDs in relname, retaining datname and pid. An unrelated local relation can no longer supply a misleading name. Discovery filters or a lack of CONNECT do not filter out visible progress rows.
• Container trust: both scratch-image build paths include the system CA bundle and license. Public CA verification can use the bundled trust store. Private CAs still require an explicit mount and sslrootcert; the default TLS mode is unchanged.
• Dependencies and validation: YAML moves from v3 to v4 with the existing collector syntax retained. Prometheus common/procfs, golang.org/x/net, and supporting dependencies are updated. CI verifies container payload/TLS behavior and inspects all DEB architectures, in addition to RPM compatibility and checksums.
• Collector descriptions: help text now distinguishes I/O bytes and operations, completed checkpoints, vacuum dead-tuple memory, and CLUSTER progress. SQL metric names, label keys, types, and units are unchanged on the same PostgreSQL version.

Upgrade notes

1. Upgrade the configuration with the binary. Merge the new pg_exporter.yml or split YAML files; package upgrades preserve local configuration. A binary-only upgrade does not fix progress SQL. The bundle still contains 58 YAML files, 96 branches, 59 namespaces, and 460 distinct metric definitions, including disabled collectors and two unexpanded histograms.
2. Check progress-label consumers. Cross-database relname values can change from an incorrect name to an OID, creating new time series. Preserve database and task identity in dashboards. Names in the connected database and names of system catalogs remain readable.
3. Choose the right health signal. /up and role endpoints reflect the latest health probe. pg_up reflects main-target collection, including fatal collector failures. Non-fatal and child-database errors require their query/server metrics. --disable-intro hides all built-in metrics, including pg_up, while HTTP health remains available.
4. Allow the PgBouncer probe connection. The main PgBouncer pool maximum changes from one to two connections. PostgreSQL keeps three on the main target and one per discovered database.
5. Keep positive timeouts on fatal collectors. Canceling a negative-timeout fatal query caches its failure for the normal TTL. A subsequent live scrape can count that cached failure and return pg_up 0 until a successful refresh. TTL zero or --disable-cache still forces a refresh on every scrape.
6. Review scrape concurrency and budgets. Excess requests or interrupted collection can return 503. A started bounded collector can extend work beyond the request budget, normally by up to its own timeout. Network stalls can last longer; neither timeout is a hard wall-clock guarantee, and connection handshakes need an appropriate DSN connect_timeout.

A real error coinciding with request cancellation can be omitted from the two pass-error counters because classification uses both the pass error and the request context. Query-level failures remain visible. A first scrape interrupted before a successful precheck leaves pg_up at zero until later recovery. Failure TTL, reload behavior, and immediate SIGTERM exit remain unchanged; this release does not add background refresh or graceful shutdown.

For upgrades from v1.4.1 or earlier, the v1.5.0 migration notes still apply, including subscription labels, receiver-state mappings, and PostgreSQL 10–13 monitoring grants. See metric compatibility, HTTP API, and scrape lifetime for the operating contracts.

Verification scope

Release validation covers the full race suite, both HTTP mux modes, module/generated-config consistency, static checks, six target builds, container TLS/payload checks, and package validation. Three cancellation regressions also passed 200 consecutive race-detector runs. The earlier reverse control failed with the interruption fix removed. On PostgreSQL 18.6, leaving during a bounded 0.8-second fatal query kept both pass-error counters at zero; the next scrape returned pg_up 1 and the cached metric without repeating the SQL.

Local acceptance of the exact release artifacts also covered PostgreSQL 9.2–9.6 with the legacy configuration, PostgreSQL 10–18 and 19 RC1 with the default configuration, and PgBouncer 1.26.1. Linux amd64/arm64/ppc64le archives and RPM/DEB packages passed runtime and installation checks; ARM64 package upgrades from 1.5.0 preserved local configuration. Darwin ARM64 passed 24 functional groups, including HTTPS authentication, reload overlap, standby promotion, and reconnect. Windows and Intel macOS received static checks only; container-based package tests did not exercise a real systemd boot. The published Docker Hub 1.6.0 and latest tags resolve to the same amd64/arm64 manifest. Both registry images were pulled and passed CA, payload, and TLS checks; their binaries match the corresponding release archives byte for byte.

Progress SQL variants were checked as a monitoring role on PostgreSQL 12, 17, and 18; the system-catalog follow-up and real cross-database VACUUM were verified on 18.6. These are scoped acceptance results, not a new exhaustive audit of every PostgreSQL release, extension, dashboard, or production workload. Composite, Patroni, pgBackRest, and PostgreSQL-log components remain on the separate snort development line and are not included in v1.6.0.

Checksums

SHA256 checksums