Re: WAL format and API changes (9.5)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL format and API changes (9.5)
Date: 2014-04-03 23:23:47
Message-ID: 20140403232347.GH17307@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> > <hlinnakangas(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-03 23:33:12 Re: WAL format and API changes (9.5)
Previous Message Tom Lane 2014-04-03 23:17:44 Re: get_fn_expr_variadic considered harmful