PgBouncer là lớp pooler nhẹ gom hàng trăm client vào vài chục kết nối thật tới PostgreSQL. Đo thật với PgBouncer 1.25: mở lại kết nối qua pooler cho 15.824 TPS so với 3.368 TPS trực tiếp — nhanh 4,7 lần; và 100 client chỉ tạo 20 backend thật đúng bằng pool_size. Ba chế độ pooling và khi nào dùng chế độ nào. PostgreSQL 16.
Prepared statement bỏ qua parse và plan khi chạy lại, nhưng plan cache có một cái bẫy: generic plan dùng ước lượng trung bình. Đo thật trên bảng lệch 99% một giá trị: generic plan ước lượng 6329 dòng trong khi thực tế 1,98 triệu — sai 313 lần, chọn Index Scan chậm hơn Seq Scan của custom plan. Cơ chế 5 lần đầu và cách ép force_custom_plan. PostgreSQL 16.
PostgreSQL có ba tầng khóa: khóa hàng (FOR UPDATE) chỉ chặn cùng hàng, khóa bảng 8 mức mà ACCESS EXCLUSIVE của DDL chặn cả SELECT, và advisory lock do ứng dụng tự định nghĩa. Đo thật bằng hai session đồng thời: cùng đối tượng chờ 3 giây, đối tượng khác chạy ngay. Vì sao một ALTER TABLE có thể treo cả ứng dụng. PostgreSQL 16.
Khi một truy vấn treo vì khóa, pg_locks và pg_blocking_pids cho biết chính xác PID nào chặn PID nào. Đo trên sự cố thật: pg_blocking_pids trả về kẻ chặn, cây chặn hiện truy vấn bị chặn lẫn kẻ chặn kèm thời gian chờ, và pg_locks thô cho thấy granted=false của kẻ đang chờ. Cách gỡ bằng pg_cancel_backend. PostgreSQL 16.
Deadlock xảy ra khi hai giao dịch giữ khóa mà bên kia cần, theo thứ tự ngược nhau. PostgreSQL tự phát hiện sau deadlock_timeout (1s) và hủy một nạn nhân với lỗi deadlock detected. Kích một deadlock thật để xem lỗi và log đầy đủ, rồi chứng minh khóa cùng thứ tự loại bỏ nó hoàn toàn. Vì sao ứng dụng phải có retry. PostgreSQL 16.
FOR UPDATE khóa hàng chủ động, nhưng nhiều worker cùng nhắm job đầu tiên sẽ nối đuôi chờ nhau. SKIP LOCKED bỏ qua hàng đang bị khóa để lấy hàng kế. Đo thật: FOR UPDATE chờ 3 giây, SKIP LOCKED lấy job kế trong 0,08 giây; 3 worker chạy cùng lúc lấy 3 job khác nhau không tranh chấp. Và NOWAIT để fail-fast. PostgreSQL 16.