On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> 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.
We actually already allocate memory in XLogInsert() :(, although only in
the first XLogInsert() a backend does... I didn't remember it, but I
complained about it before:
http://archives.postgresql.org/message-id/4FEB223A.3060707%40enterprisedb.com
I didn't realize the implications for it back then and thus didn't press
hard for a change, but I think it should be fixed.
> 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.
We could simply allocate enough scratch space for the state at process
startup. I don't think there'll ever be a need for XLogInsert() to be
reentrant, so that should be fine.
> 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.
Agreed. There's some pretty ugly code around this.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services