Re: XLByte* usage

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: XLByte* usage
Date: 2012-12-17 18:30:10
Message-ID: 20121217183010.GA26826@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-12-17 23:45:51 +0530, Pavan Deolasee wrote:
> On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
> <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>
> >>
> >
> > I probably did not mean increasing that to beyond 64-bit. OTOH I
> > wondered if we would ever want to steal a few bits from the LSN field,
> > given the numbers you just put out. But it was more of a question than
> > objection.
> >
>
> BTW, now that XLogRecPtr is uint64, can't we change the pd_lsn field
> to use the same type ? At least the following comment in bufpage.h
> looks outdated or at the minimum needs some explanation as why LSN in
> the page header needs to split into two 32-bit values.
>
> 123 /* for historical reasons, the LSN is stored as two 32-bit values. */
> 124 typedef struct
> 125 {
> 126 uint32 xlogid; /* high bits */
> 127 uint32 xrecoff; /* low bits */
> 128 } PageXLogRecPtr;

pg_upgrade'ability. The individual bytes aren't necessarily laid out the
same with two such uint32s as with one uint64.

Greetings,

Andres Freund

--
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 Tom Lane 2012-12-17 18:34:52 Re: Makefiles don't seem to remember to rebuild everything anymore
Previous Message Tom Lane 2012-12-17 18:23:04 Re: Makefiles don't seem to remember to rebuild everything anymore