On Mon, Sep 20, 2021 at 10:24 AM Antonin Houska <a...@cybertec.at> wrote: > > Amit Kapila <amit.kapil...@gmail.com> wrote: > > > On Fri, Sep 17, 2021 at 9:50 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > > > > On Tue, Sep 14, 2021 at 10:51:42AM +0200, Antonin Houska wrote: > > > > > > * What happened with the idea of abandoning discard worker for the sake > > > of simplicity? From what I see limiting everything to foreground undo > > > could reduce the core of the patch series to the first four patches > > > (forgetting about test and docs, but I guess it would be enough at > > > least for the design review), which is already less overwhelming. > > > > > > > I think the discard worker would be required even if we decide to > > apply all the undo in the foreground. We need to forget/remove the > > undo of committed transactions as well which we can't remove > > immediately after the commit. > > I think I proposed foreground discarding at some point, but you reminded me > that the undo may still be needed for some time even after transaction > commit. Thus the discard worker is indispensable. >
Right. > What we can miss, at least for the cleanup of the orphaned files, is the *undo > worker*. In this patch series the cleanup is handled by the startup process. > Okay, I think various people at different point of times has suggested that idea. I think one thing we might need to consider is what to do in case of a FATAL error? In case of FATAL error, it won't be advisable to execute undo immediately, so would we upgrade the error to PANIC in such cases. I remember vaguely that for clean up of orphaned files that can happen rarely and someone has suggested upgrading the error to PANIC in such a case but I don't remember the exact details. -- With Regards, Amit Kapila.
