Re: Orphaned Files in PostgreSQL

Hi,

On Wed, Sep 23, 2026 at 11:55 PM Greg Burd <greg(at)burd(dot)me> wrote:
> Hey Ashutosh!
>
> Thanks for the excellent email kicking off this thread, I couldn't agree
> more about the issue.

Thanks to you too for working on this project. I am glad to know that
I am not alone on this path of finding a solution to this problem.

I started in a different place, asking myself if
> I could resurrect UNDO from ZHEAP without modifying HEAP at all (because
> I tried and it didn't help, other different table AMs might find benefit
> but HEAP is rather solid as it is) and if I could how would I demonstrate
> and justify it without adding a new table AM or modifying HEAP?
>
> I used to work on Berkeley DB and one of the features was its ability to
> WAL log UNDO/REDO records for "filesystem operations" and then during
> recovery tidy up and make things consistent. That struck me as a solid
> first application of UNDO in Postgres, so I created that and called it
> FILEOPS (because I'm not creative at all).
>

Thanks for sharing all of this. I will surely go through it once you
make it public.

>
> I'm spending a lot of time this week cleaning up the UNDO and FILEOPS
> patches in hopes of posting them soon as either an RFC or a proposed
> patch set. I do have new table AMs that use it, but I don't think
> they are ready for prime time yet. There are other use cases for UNDO
> also like BLOB/CLOBs etc. that I think might be interesting and if I
> can get the integration with nbtree and hash correct there are also
> benefits for indexes.
>

Sure, please share it, and I will be happy to contribute in whatever
way I can. I see that you shared this information earlier here [0],
but I somehow missed it, perhaps because I was not part of that
discussion or did not realize that it was related to the work being
discussed here.

> That said, it's a large change and one that has philosophical and
> technical challenges before the community could even consider merging
> it in. I have hope, but it'll be a long road.
>

Yes, that seems to be pretty obvious considering the complexity involved here.

> Your approach has less overhead/history to deal with. I'll need to
> dig into it more to appreciate the direction you've taken but I do
> agree that it needs to happen somehow and so I don't see this as a
> competing idea at all.
>

Well, it seems like this approach has already been discussed/proposed
earlier here [1] by Chris but somehow it didn't move forward. I still
need to understand the details and any blockers that prevent it from
progressing.

[0] - https://www.postgresql.org/message-id/5d89549c-117e-45ae-b934-a2bb71c82a79%40app.fastmail.com
[1] - https://www.postgresql.org/message-id/CAN-RpxDBA7HbTsJPq4t4VznmRFJkssP2SNEMuG%3DoNJ%2B%3DsxLQew%40mail.gmail.com

--
With Regards,
Ashutosh Sharma.