On 2014-04-03 19:08:27 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas > > <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
