a month ago
I have a Postgres service that crash-looped with "PANIC: could not write to file pg_wal/xlogtemp.*: No space left on device" after a routine data write filled its volume. Two issues:
-
Resize doesn't take effect: I resized the volume from 433 MB to 500 MB (the max allowed on my current plan) in the dashboard and redeployed multiple times, but every startup log still reports "pgbackrest: volume 433 MiB" -- the running container never actually got the larger volume, and the database stayed stuck crash-looping (WAL replay fails every restart with "No space left on device" before it can even finish recovery).
-
A brand-new, essentially empty instance also filled up almost immediately: I deleted the stuck Postgres service and created a fresh one on the same plan. After only
alembic upgrade headcreating six empty tables and two trivial read-only queries, it hit the identical "No space left on device" PANIC within about 2 minutes -- with "pgbackrest: volume 433 MiB" logged again. That's an unreasonably small amount of usage to exhaust a 433 MB volume, which suggests either the baseline Postgres+pgbackrest overhead on this plan tier is abnormally close to the volume cap, or repeated crash-loop restarts are themselves consuming disk space (partial WAL/temp files from interrupted redo attempts) faster than expected.
Could you look into (a) why the volume resize isn't propagating to the running container, and (b) why so little usage fills the volume so fast? Happy to share deployment/service IDs if useful.
1 Replies
a month ago
Your volume is provisioned at 500 MB, which is the Trial plan maximum, and the "433 MiB" pgbackrest reports is the usable capacity after filesystem overhead (ext4 metadata, journal, reserved blocks), not evidence of a failed resize. Both your current and previous volumes show 500 MB provisioned, so the resize did not fail to propagate. The core issue is that 0.5 GB is extremely tight for Postgres with pgbackrest: the WAL, pgbackrest repository, and system catalogs consume a large share of that at baseline, and crash-loop restarts compound it because each interrupted WAL replay leaves partial temp files that accumulate. Trial volumes cannot be resized beyond 0.5 GB. Upgrading to Hobby ($5/month) raises the volume cap to 5 GB, which gives Postgres the headroom it needs.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 1 month ago