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/[email protected] [1] https://postgr.es/m/[email protected]
