a month ago
Project: exemplary-celebration (production)
Service: Postgres (ID 75048aa7-f599-4ab2-adfc-5fc75be633c9)
Deployment: ee8c1c84-dded-43a6-9086-03ca58decd1b
Volume: postgres-volume (ID 79d3cc99-f691-4d4f-a5e0-29c5a8603f2a)
I resized the Postgres volume from 10GB → 50GB about an hour ago. railway volume list confirms 50000MB, but the container still hits "FATAL: could not write to file pg_wal/xlogtemp.30: No space left on device" on every restart. I've redeployed multiple times (bind-mount UUIDs change each time), same result — the filesystem inside the container was not expanded to match the new volume size.
Can someone on the team please run resize2fs (or the equivalent) on the backing volume? WAL replay completes cleanly every restart (redo done at 0/8EFFFF08), so data integrity is fine — only the xlogtemp write is failing.
Crash started at 2026-04-17 01:29 UTC mid data-migration.
Thanks 🙏
1 Replies
a month ago
Hey, the volume resize didn't fully apply to the underlying disk, which is why Postgres was crash looping on WAL writes even though the dashboard showed 50 GB. I've fixed it and redeployed the service. You should now see the full ~50 GB of disk space available to Postgres, and the data migration should be able to resume once the new deployment is healthy.
Status changed to Solved brody • about 1 month ago