Scaling the Wall of Text: Logging Best Practices in PostgreSQL
summary
PostgreSQL logging must be configured: set log_line_prefix to include timestamp, PID, session/tx id, user, DB and client so you can trace who did what; use log_destination/logging_collector and a separate log partition to avoid IO interference; use log_min_duration_statement, sampling (v12–13) and log_statement selectively to catch slow or fatal queries; grep/sed/awk, Splunk, pgbadger and auto_explain speed analysis. Proper logs cut incident investigation from days to hours; only ~40% keep defaults.
AI-written summary · about
chapters (12)
- 0:00Intro
- 1:15Why logging is important
- 2:57Scenarios
- 3:24What logging can tell you
- 4:25PostgreSQL logging parameters
- 4:48Where to log
- 7:59What to log
- 10:13When to log
- 15:51What to log again?
- 18:55The importance of log_line_prefix
- 23:23What to look for
- 26:19Summary
related talks
43mLogging Not Just for Lumberjacks
30mPostgreSQL Observability: The Log Configuration That Changes Everything
47mIdentifying Slow Queries and Fixing Them!
57mQuery Logging and Workload Analysis
49mLeveraging pgBadger for Effective PostgreSQL Troubleshooting
45mDebugging Databases for Developers
57mPostgreSQL When It's Not Your Job
58mScaling Postgres