When hundreds of connections queue on WALWriteLock in PostgreSQL, the bottleneck is rarely disk write speed alone. A severe outage with more than 1100 backends blocked on WALWrite revealed an overlooked architectural detail in Postgres write-ahead log management.
PostgreSQL does not implement a dedicated group commit queue. Instead, it overloads WALWriteLock to serve two fundamentally distinct roles at the same time. The process that holds the lock performs the physical write and issues the fsync call, while all other waiting processes queue behind it simply to check if that sync operation already persisted their log sequence number.
Because every backend must acquire this exact lock to verify whether its transaction has been covered, any transient I/O delay or autovacuum spike causes a catastrophic pile-up. Backends spend precious CPU cycles contending for a lock merely to discover that their work was already complete.
Database scalability often hinges on whether your concurrency primitives separate work execution from status notification.




