Re: In-placre persistance change of a relation

A bit out of the blue, but I remembered the reason why I could make
that change I previously agreed seemed off. Just thought I’d let you
know.

At Tue, 05 Nov 2024 13:25:26 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
me> > the commit process to keep the window as small as possible, but if it
me> > nevertheless happens, the consequences are pretty bad if you remove a
me> > relation file that is in fact needed.
me>
me> However, on second thought, it does seem odd. I may have confused
me> something here. If pendingDeletes is restored and undo cancellation is
me> implemented, this change would be unnecessary.

The change would indeed be incorrect if updates to mapped relations
could occur within subtransactions. However, in reality, trying to
perform such an operation raises an error (something like “cannot do
this in a subtransaction”) and is rejected. So, there’s actually no
path where the removed code would be used. That’s why I judged it was
safe to remove that part. However, from that perspective, I think the
explanations in the comments and commit messages were somewhat lacking
or missed the point.

Currently, I’m leaning toward implementing per-relation undo
cancellation. Previously, this path was active even during normal
aborts, so there were performance concerns, but now it only runs
during recovery cleanup, so there are no performance issues with
handling cancellation. In the current state, the code has been
simplified overall.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center