Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> (Instead of using a new XLogRegisterBuffer() function to register the
>> buffers, perhaps they should be passed to XLogInsert as a separate list or
>> array. I'm not wedded on the details...)
> That would have the advantage of avoiding the function-call overhead,
> which seems appealing.
You're kidding, right? One function call per buffer touched by an update
is going to be lost in the noise.
A somewhat more relevant concern is where are we going to keep the state
data involved in all this. Since this code is, by definition, going to be
called in critical sections, any solution involving internal pallocs is
right out. The existing arrangement keeps all its data in local variables
of the function doing the update, which is probably a nice property to
preserve if we can manage it. That might force us to do it as above.
I'd still like something that *looks* more like a list of function calls,
though, even if they're macros under the hood. The existing approach to
setting up the XLogRecData chains is awfully prone to bugs of omission.
There are a few places that went so far as to set up custom macros to help
with that. I'm not a fan of doing the same thing in randomly different
ways in different places; but if we did it that way uniformly, it might be
better/safer.
regards, tom lane