Hey, sorry about this. You're right that the volume resize didn't fully apply, so your database was still working with the original ~480 MB of space despite the dashboard showing 5 GB.

We've corrected this on our end and redeployed your service. Your Postgres volume now has the full ~4.7 GB of available disk space.

Hey, thanks for jumping on this and getting the filesystem resized.

Unfortunately after your redeploy, Postgres still isn't starting. Here are the logs from the Postgres service:

2026-04-07 00:13:17.472 UTC [6] LOG: could not open file "postmaster.pid": Input/output error; continuing anyway

2026-04-07 00:13:17.473 UTC [140] FATAL: could not open file "global/pg_filenode.map": Input/output error

To my knowledge, the database was actually running after my manual recovery steps — the issues seem to have started after your resize/redeploy. A few follow-up

questions:

1. What exactly happened during the redeploy — did you remount the volume or make any changes to the data directory itself?

2. Can you verify the volume is healthy at the block device level and that the filesystem is readable?

3. Do you have a snapshot of the volume from before your intervention that could be restored?

I'd really like to recover the data if possible. Can you help get this sorted?

Fixed and confirmed back online. Sorry about that!

thank you, appreciate the help. jfyi several / all of my db indexes were corrupted. had to reindex.

```

sqlalchemy.exc.InternalError: (sqlalchemy.dialects.postgresql.asyncpg.InternalServerError) <class 'asyncpg.exceptions.IndexCorruptedError'>: index "pg_toast_16436_index" contains unexpected zero page at block 121

HINT: Please REINDEX it.

```

actually seeing more widespread data corruption.

sqlalchemy.exc.InternalError: (sqlalchemy.dialects.postgresql.asyncpg.InternalServerError) <class 'asyncpg.exceptions.DataCorruptedError'>: missing chunk number 0 for

toast value 24626 in pg_toast_16436

I deleted my data to recover my environment and restore service. you guys should probably revisit your volume resizing - it resulted in total data loss.

The volume resize bug that prevented the filesystem from extending has been fixed, and we apologize for that. Going forward, volume resizes will correctly expand the filesystem automatically. That said, the data loss was a result of the manual recovery steps taken (deleting WAL files and running pg_resetwal), not the resize bug itself. The resize created the disk pressure, but the unrecoverable corruption came from those manual interventions.

Possibly, but you should know the system was working without corruption issues after my manual interventions. Corruption showed up after your resize and redeploy intervention.

We understand the timing, but the data corruption is consistent with the expected risks of your manual recovery steps. The resize bug was ours and has been fixed. The subsequent data loss, however, was a result of your manual interventions.

The underlying issue has been resolved. If you still are having a problem with your volume it may require individual intervention. Please reply here and let us know and we can try to address it. Thanks!