A lightweight lock (LWLock), sometimes called a latch, protects PostgreSQL shared-memory data so concurrent reads and writes remain consistent. Accessing the same objects from many connections can make these locks heavily contended; because queuing is not fair, lockers may slow one another and reduce throughput. section 6.3
The 2,000-connection mistake
A workload that opens 2,000 clients may appear highly parallel, but a 2,000-client pgbench run produced only 352.1 TPS with 5,535 ms average latency. Lower client counts produced better throughput and latency, showing why unrestricted concurrency can overload shared resources.
Use these operational signals and responses:
- Check pg_stat_activity for abundant wait_event_type: LWLock entries when excessive concurrency is suspected. section 6.3
- Restrict client connections and let application requests queue; if that is impossible, place PgBouncer between the application and database. section 6.3
