looking at those timestamp I think your postgres service stopped after starting, not sure if this caused by incident at May 20, but you can try redeploy source image and see if that fixes it

go to your postgres service > open command palette (Ctrl+k on PC) > click "Redeploy source image"

if this helps, then the problem caused by corrupted cached image, doing step above will pull fresh postgres image

also, does your postgres works fine before?

I’d be careful with this one. invalid xl_info + could not locate a valid checkpoint record usually isn’t just a normal startup delay. It can mean the WAL/checkpoint state on the Postgres volume is damaged.

So I wouldn’t delete the volume or create a fresh DB over it.

Redeploy source image is okay to try if the image is stale, but if the attached volume has corrupted WAL, redeploying the image probably won’t fix that part. Before any destructive recovery, I’d preserve the volume first / ask Railway if they can snapshot or copy it.

Cleanest path is:

1. stop anything writing to that DB
2. check if you have a backup/PITR to restore from
3. preserve/copy the current volume
4. only then attempt recovery on a copy

pg_resetwal is usually a last resort for this kind of thing, and I’d only touch it after copying the volume, because it can make data loss worse if used on the only copy.