Re: Orphaned Files in PostgreSQL

Hi Ashutosh,

On 23 Sep 2026, Ashutosh Sharma wrote:
> Please take a look and let me know.

At the design level, one manifest per XID still means a pg_fsync() for
each appended record, including during redo. Have you considered WAL
plus delayed manifest synchronization, along the lines Andres
suggested [0]? It would be useful to compare small-DDL and replay
costs before settling on synchronous per-record writes.

From reading v2, I am concerned about mapped catalog rewrites.
write_relmap_file() flushes XLOG_RELMAP_UPDATE before calling
RelationPreserveStorage(), where the patch now records PRESERVE.
A crash between those steps leaves the new mapping durable, but the
creating transaction uncommitted and its manifest without PRESERVE.
relmap_redo() does not preserve the storage either. Wouldn't the new
end-of-recovery cleanup then remove files needed by the mapped catalog?

Could preservation be part of the relmap update's recovery semantics?
A crash test in that window during VACUUM FULL of a mapped catalog
seems particularly important. I haven't run that reproducer yet.

The truncated-manifest test expects startup to fail. Can a crash during
a normal append leave that state without replay repairing it? If so,
could we retain the uncertain files rather than refuse startup?

Also, Greg recently mentioned renewed UNDO/FILEOPS work [1]. It may
be worth coordinating the scope with him. Preventing new orphans and
handling existing ones, as needed for online checksums, are separate
parts of the problem.

Thank you!

Best regards, Andrey Borodin.

[0] https://postgr.es/m/20170814185632.zodm5qykgss7ud32@alap3.anarazel.de
[1] https://postgr.es/m/5d89549c-117e-45ae-b934-a2bb71c82a79@app.fastmail.com