What's changed: Initial version (topic G4)
4.1Common failure patterns
Learn the basics of failure triage: identifying issues from error messages, server stoppage, data loss, OS resource exhaustion, and process-state analysis; the timeout parameters statement_timeout, lock_timeout, and idle_in_transaction_session_timeout; synchronous_commit and restart_after_crash which govern post-crash consistency; server control via pg_ctl; and the lock-management ceiling max_locks_per_transaction.
Responding to a production database failure starts with precisely triaging what actually happened. Even a single symptom like "cannot connect to the server" can stem from a crashed process, OS resource exhaustion (full disk, low memory), a network outage, or simply hitting the connection limit under load. The Gold exam tests the judgment to identify the nature of a failure from error messages, process state, and configuration parameters, and choose the right first response.
4.1.1Diagnosis: error messages, processes, and resources
- Diagnosing from error messages—PostgreSQL logs (routed via
log_destination) tag entries with severities likeFATAL,PANIC, andERROR.PANICis the most severe: it crashes the entire server process and triggers an automatic restart. Messages likecould not write to file(write failure) orout of memorytypically signal OS resource exhaustion. - Analyzing server stoppage, data loss, OS resource exhaustion, and process state—the standard first-pass triage is checking whether the postmaster and backend processes are alive with
ps, disk usage withdf/du, and memory withfree. A full disk directly blocks WAL writes and can escalate to a crash, making it a top-priority cause to rule out.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.