7 days ago
Hi, I have the same issue described in these two related threads:
- https://station.railway.com/questions/resizing-database-error-9a586185
- https://station.railway.com/questions/database-is-crashing-after-resize-from-5-9b326eb4
Project ID: 8a58284b-2194-4a03-b22f-8a4fd5b5d96e
Environment: production (2d52fa6f-3330-4ae1-99c1-cf47d9f7a7d6)
Postgres service ID: a4bef25a-aa09-48c7-94d6-6d5061d3a8bc
Volume ID: 16e82507-c5fd-4593-8f28-58b587523878
Latest deployment ID: da699568-7790-4141-82c9-0a7abe89534e
What happened:
-
A bulk INSERT filled the volume to 500MB (old Hobby limit), crashing Postgres mid-WAL-recovery with:
FATAL: could not write to file "pg_wal/xlogtemp.59": No space left on device
-
I upgraded to paid Hobby (up to 5GB volume) and requested a volume resize.
-
I've since tried both a plain restart and a full redeploy of the Postgres service — same crash every time, identical error, disk usage still reporting ~494MB used with no headroom.
Like the threads above, it looks like the resize request isn't actually taking effect on the physical volume even though the plan/API accepted it.
This is a production database (CRM leads, chat history) with NO backups available on this plan — I have not touched/recreated the volume, waiting for a proper fix. Please check/apply the resize on your end, or let me know if there's anything else needed to trigger it. Thanks!
1 Replies
7 days ago
Your Postgres volume is still at its original 500MB because every resize attempt was rejected for exceeding the 5GB Hobby plan cap. None of them took effect, which is why the disk is still full and WAL recovery keeps failing with ENOSPC. To fix this, open the volume's settings page in your project, resize to a value at or below 5000MB (e.g. 2GB would give plenty of headroom), then redeploy the Postgres service so it picks up the new capacity and completes WAL recovery.
Status changed to Awaiting User Response Railway • 7 days ago