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

Hi Bertrand,

On Thu, Jun 25, 2026 at 1:06 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)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.

--
Thanks, Amit Langote