Re: In core use of RegisterXactCallback() and RegisterSubXactCallback()

On Thu, Jun 25, 2026 at 2:25 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Thu, Jun 25, 2026 at 1:06 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> > Hi hackers,
> >
> > while working on [1] I wanted to make use of RegisterSubXactCallback() and
> > realized that RegisterXactCallback() has this comment:
> >
> > "
> >  * These functions are intended for use by dynamically loaded modules.
> >  * For built-in modules we generally just hardwire the appropriate calls
> >  * (mainly because it's easier to control the order that way, where needed).
> > "
> >
> > So I thought of hardwiring the call directly in Start/Commit/AbortSubTransaction()
> > instead.
> >
> > Then I realized that b7b27eb41a5 just made use of RegisterXactCallback() and
> > RegisterSubXactCallback(), so I'm wondering if it should hardwire the calls
> > instead?
> >
> > Note that the other RegisterSubXactCallback() and RegisterXactCallback() look
> > legitimate to me (as in loadable modules).
>
> Thanks for flagging this.
>
> Note the RegisterSubXactCallback() call from b7b27eb41a5 was already
> removed by a later fix (4113873a) that confined fast-path batching to
> the top transaction level, so only the RegisterXactCallback() remains.
> You're right that the header comment points toward hardwiring for
> built-in code. I took the shortcut of using Register* because the RI
> fast-path callback has no ordering dependency on the other hard-wired
> work in Commit/AbortTransaction(), but I agree it should follow the
> convention. I'll work up a patch converting it to a hardwired
> AtEOXact_RI() called from CommitTransaction(), PrepareTransaction()
> and AbortTransaction(), and post it on this thread.

Here is a patch to do so.

It's a mechanical conversion, except the new AtEOXact_RI() takes
isCommit and asserts that the fast-path cache was already torn down by
commit, with a WARNING in non-assert builds. A survivor would mean a
trigger batch went unflushed. On abort it's expected, so it just
resets.

-- 
Thanks, Amit Langote