PostgreSQL's `max_worker_processes` hasn't budged since 2014, but parallel queries, logical replication, and extensions keep demanding slots.

`max_wal_size` is a checkpoint trigger, not a maximum—and the real cost is paid by setting it too low, not too high.

WAL senders have their own connection pool, separate from max_connections—but it fills up faster than you'd think.

max_sync_workers_per_subscription parallelizes table copies across tables, not within them.

`max_standby_streaming_delay` buys you replication lag, not query time—and when the budget runs out, queries get canceled regardless of how long they've…

Replication slots can silently fill your disk and crash the primary, or you can set `max_slot_wal_keep_size` to kill a stalled replica instead.

`max_replication_slots` sizes a shared-memory array that holds every replication slot, regardless of type or state.

Prepared transactions are orphaned sessions that hold locks and block vacuum indefinitely.

Predicate locks outlive their transactions in PostgreSQL's serializable isolation, so the default `max_pred_locks_per_transaction` of 64 sizes a table holding…

WalShadow replicates PostgreSQL to ClickHouse by decoding the physical WAL stream itself, not logical decoding.