2 months ago
Every time any of my databases gets full, I'm unable to restart them due to some data corruption. It has happened a bunch of times, and I can only solve it by mounting the volume on a new DB.
4 Replies
2 months ago
Hi there, this is a known issue where resizing a volume doesn't always expand the underlying filesystem, causing Postgres to crash on startup. We know the remount workaround isn't ideal, especially when it keeps happening. If you hit this again, let us know and we can expand the filesystem from our side, that can be faster than remounting. We've tracked this as a bug to fix the automatic expansion.
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
We've confirmed your scroll-db volume is hitting the known filesystem expansion issue - WAL recovery completes but the end-of-recovery checkpoint fails due to no space. We're escalating now to get the filesystem expanded from our side.
Status changed to Awaiting User Response Railway • 2 months ago
2 months ago
We've expanded the filesystem on your scroll-db volume to match the full 100 GB allocation and redeployed the service. It should come back up shortly. Let us know if you hit this on any of your other databases and we can apply the same fix.
2 months 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 2 months ago