FATAL: the database system is in recovery mode
PostgreSQL crashed (often OOM-killed) and is replaying WAL to recover.
the database system is in recovery modeterminated by signal 9: Killed Meaning
When a backend process dies abnormally, the postmaster restarts all sessions and runs recovery. The PostgreSQL log shows which process was killed and why.
Common causes
- A backend killed by the OOM killer
- Server crash/power loss
- Storage errors
⚡ Quick fix
- Check the PostgreSQL log and dmesg for OOM kills
- Reduce work_mem/max_connections or add RAM
- Let recovery finish
Detailed fix by platform
Linux
dmesg -T | grep -i -E 'killed process|out of memory'
How to diagnose
- Cause — What terminated the backend?
- Recent change — Did it start after a deploy, upgrade, or configuration change? Compare with the last working version.
🔧 Still not fixed?
Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:
Similar errors
Most viewed in PostgreSQL
- could not connect PostgreSQL: could not connect to server / connection refused — Is the server running on host and accepting TCP/IP connections?
- pg_restore text dump pg_restore: error: input file appears to be a text format dump. Please use psql.
- 25P02 ERROR: current transaction is aborted, commands ignored until end of transaction block
Other ways to find it
Where this error sits
Origin: Data. Errors that are often confused with or caused by this one (click to open):
🧠 Still stuck? Analyze your error
Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.
💬 What worked for others
No tips yet — did something else fix this for you?
Share what worked for you
Tips are checked by an editor before they appear. Links are removed.
Report a correction or suggest an improvement
Last updated 13 Oct 2026