Hi, Thank you for taking a quick look at the proposed changes and sharing your feedback.
On Wed, Sep 23, 2026 at 6:09 PM Andrey Borodin <[email protected]> wrote: > > 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] > I have not yet reviewed the earlier discussions in these threads in enough detail. It appears that the approach I am proposing overlaps with Chris Travers earlier work, but I do not yet understand why that work did not proceed, whether because of unresolved technical issues or other considerations. I will review those discussions before deciding how to revise this proposal. The concern raised about mapped relation files looks valid and requires additional handling. However, before working out that fix, I would first like to understand the earlier proposals and reconsider the overall strategy in that context. -- With Regards, Ashutosh Sharma.
