Re: [PATCH 02/16] Add zeroRecPtr as a shortcut for initializing a local variable to {0, 0}

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 02/16] Add zeroRecPtr as a shortcut for initializing a local variable to {0, 0}
Date: 2012-06-14 15:29:46
Message-ID: 201206141729.46358.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, June 14, 2012 04:04:22 PM Robert Haas wrote:
> On Thu, Jun 14, 2012 at 9:57 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> > On Thursday, June 14, 2012 03:50:28 PM Robert Haas wrote:
> >> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
> >
> > wrote:
> >> > This is locally defined in lots of places and would get introduced
> >> > frequently in the next commits. It is expected that this can be
> >> > defined in a header-only manner as soon as the XLogInsert scalability
> >> > groundwork from Heikki gets in.
> >>
> >> This appears to be redundant with the existing InvalidXLogRecPtr,
> >> defined in access/transam.h.
> >
> > Oh. I didn't find that one. Judging from all the code defining local
> > variants of it I am not alone in that... Why is it in transam.h and not
> > xlogdefs.h?
>
> Uh, not sure. We used to have a variable by that name defined in a
> bunch of places, and I cleaned it up some in commit
> 503c7305a1e379f95649eef1a694d0c1dbdc674a. But if there are still more
> redundant definitions floating around, it would be nice to clean those
> up.
Forget it, they are in things that don't link to the backend... /me looks
forward to the 64bit conversion of XLogRecPtr's.

Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-06-14 15:36:56 Re: sortsupport for text
Previous Message Robert Haas 2012-06-14 15:04:34 Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)