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 <x4mmm@yandex-team.ru> 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/20170814185632.zodm5qykgss7ud32@alap3.anarazel.de
> [1] https://postgr.es/m/5d89549c-117e-45ae-b934-a2bb71c82a79@app.fastmail.com
>
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.
