Hi Bertrand, On Thu, Jun 25, 2026 at 1:06 PM Bertrand Drouvot <[email protected]> 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
