Re: XLByte* usage

On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> > On 17.12.2012 11:04, Pavan Deolasee wrote:
> >> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
> >> <hlinnakangas(at)vmware(dot)com> wrote:
> >>> I've still used XLByte* macros, but I agree that plain <=> are easier to
> >>> read. +1 for using <=> in new code.
>
> >> Do we ever see us changing this from 64-bit integers to something else
> >> ? If so, a macro would be much better.
>
> > I don't see us changing it again any time soon. Maybe in 20 years time
> > people will start overflowing 2^64 bytes of WAL generated in the
> > lifetime of a database, but I don't think we need to start preparing for
> > that yet.
>
> Note that to get to 2^64 in twenty years, an installation would have had
> to have generated an average of 29GB of WAL per second, 24x7 for the
> entire twenty years, with never a dump-and-reload. We're still a few
> orders of magnitude away from needing to think about this.

Agreed. And it seems achieving such rates would require architectural
changes that would make manually changing all those comparisons the
tiniest problem.

> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
> we'd move to 128-bit integers, which will surely be available on all
> platforms by then. So +1 for using plain comparisons --- in fact, I'd
> vote for running around and ripping out the macros altogether. I had
> already been thinking of fixing the places that are still using memset
> to initialize XLRecPtrs to "invalid".

I thought about that and had guessed you would be against it because it
would cause useless diversion of the branches? Otherwise I am all for
it.

Greetings,

Andres Freund

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