PostgreSQL 19 enables lock contention logging by default and adds granular process-level log controls

PostgreSQL 19’s default `log_lock_waits` setting eliminates a common blind spot in performance tuning. Previously, operators had to explicitly enable this feature to detect sessions stalled on locks, often discovering contention only after user complaints. The change reflects a shift toward proactive observability, though it may increase log volume for workloads with frequent short-lived locks. Teams relying on log-based alerting should verify their tooling handles the new messages without false positives.

The new per-process log verbosity controls address a long-standing pain point for debugging specific subsystems. Prior versions forced a trade-off between drowning in DEBUG-level logs or missing critical details from background processes like the checkpointer. The syntax supports backward compatibility while enabling targeted logging (e.g., `autovacuum:debug1`). This granularity is particularly useful for troubleshooting replication lag or WAL generation issues, where the root cause often lies in a single process type.

Separating autoanalyze logging from autovacuum logging (`log_autoanalyze_min_duration`) and adding WAL byte-level metrics (`wal_fpi_bytes`) provide more precise instrumentation for two of PostgreSQL’s most opaque operations. Autoanalyze runs are typically brief but critical for query planning, while VACUUM’s WAL generation can unexpectedly dominate storage I/O. The new counters help distinguish between WAL from full-page writes and other operations, though interpreting these metrics requires understanding PostgreSQL’s checkpoint behavior and page-level storage mechanics.

The changes introduce minimal operational overhead but may require adjustments to monitoring pipelines. Tools parsing autovacuum logs must now account for separate ANALYZE entries, and dashboards should expose `wal_fpi_bytes` alongside existing WAL metrics. The per-table `log_autoanalyze_min_duration` override offers flexibility for high-churn tables but could complicate log aggregation if overused. Teams should review their logging infrastructure before upgrading to avoid missing critical signals in the new, more detailed output.