Database Errors at the OS Layer
Most database problems aren’t SQL bugs — they’re OS-level: file descriptors, disk I/O, networking, memory pressure. Recognizing the OS signature of common DB failures saves hours. The ten errors below cover PostgreSQL, MySQL/MariaDB, and Redis from a sysadmin perspective.
#121 – connection refused (DB not running)
Description: Clients get ECONNREFUSED on the database port.
Solution: systemctl status postgresql; check journalctl -u postgresql -n 50; verify port: ss -tlnp | grep :5432; check the DB’s data directory hasn’t run out of space.
#122 – too many connections / max_connections exceeded
Description: New connections are rejected because the DB hit its connection cap.
Solution: SELECT count(*) FROM pg_stat_activity;; raise max_connections in postgresql.conf (requires restart); or use connection pooler (PgBouncer); idle-in-transaction is the common offender.
#123 – password authentication failed for user
Description: DB rejects credentials despite the password being correct.
Solution: Check pg_hba.conf for the right method (md5/scram-sha-256/peer); reload: systemctl reload postgresql; reset password: ALTER USER alice WITH PASSWORD 'new';.
#124 – deadlock detected
Description: A query fails because two transactions are each waiting on locks the other holds.
Solution: pg_stat_activity shows blocked queries; SELECT pg_blocking_pids(pid), * FROM pg_stat_activity to find locks; long-term: shorter transactions, consistent lock order, lower isolation level if appropriate.
#125 – replication lag growing
Description: Replicas fall further and further behind the primary’s WAL or binlog.
Solution: On primary: SELECT * FROM pg_stat_replication;; replica: pg_stat_wal_receiver; check network bandwidth; check disk I/O on replica; max_wal_senders, wal_keep_size.
#126 – archive_command failure
Description: WAL not archiving; risks running out of disk if archive_mode is on.
Solution: Check archive command output; pg_archivecleanup; verify destination has space and is reachable.
#127 – MySQL: Lost connection during query
Description: Long queries are dropped mid-execution with “Lost connection to server.”
Solution: max_allowed_packet too small; wait_timeout hit on long queries; network instability; raise both, check OS-level network issues.
#128 – Redis: OOM command not allowed when used memory > maxmemory
Description: Writes to Redis fail because it hit maxmemory and has no eviction policy.
Solution: Configure eviction policy: maxmemory-policy allkeys-lru; raise maxmemory; or shrink working set.
#129 – PostgreSQL: could not write to file (disk full)
Description: DB refuses writes because the data directory’s filesystem is full.
Solution: df -h; if data dir full: free space immediately or DB will refuse writes. Vacuum bloat: VACUUM FULL if blocking allowed.
#130 – transaction aborted (long-running stuck)
Description: A transaction has been open for hours, blocking VACUUM and holding locks.
Solution: SELECT pid, now()-query_start AS age, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY age DESC;; SELECT pg_cancel_backend(pid); for graceful or pg_terminate_backend as last resort.
Conclusion
- Connection-pool every app. Direct connections to Postgres at scale = exhaustion.
- Monitor replication lag — silent until you fail over and lose data.
- Configure WAL archive destination to fail loudly, not silently fill the disk.
- Don’t store DB on the OS root volume. Separate mount = dies independently.
- Keep an eye on
pg_stat_activity/SHOW PROCESSLISTin a production console.