From: | "William ZHANG" <uniware(at)zedware(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Database file compatability |
Date: | 2005-09-28 15:14:08 |
Message-ID: | dhecnp$s7o$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> wrote
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
> news:1223(dot)1127878072(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> >
> > There are no platforms for which ALIGNOF_SHORT is different from 2.
> > I don't think there are any platforms we care about where ALIGNOF_INT
> > is different from 4. The cases of interest are ALIGNOF_DOUBLE,
> > ALIGNOF_LONG, ALIGNOF_LONG_LONG_INT (note that MAXIMUM_ALIGNOF is
> > just the largest of these). In practice "long int" is the same type
> > as either "int" or "long long int", so ALIGNOF_LONG isn't a distinct
> > case either. What it comes down to is that MAXIMUM_ALIGNOF is
> > sufficient to tell the difference between the platforms we need to
> > deal with. If you have a counterexample, tell us about it.
> >
> (1)
> Yes, ALIGNOF_SHORT is always 2.
>
> (2)
> There is a possible sequence like this:
>
> ALIGNOF_LONG 4
> ALIGNOF_DOUBLE 8
> MAXIMUM_ALIGNOF 8
>
> vs.
>
> ALIGNOF_LONG 8
> ALIGNOF_DOUBLE 8
> MAXIMUM_ALIGNOF 8
>
> Eg.
> http://developers.sun.com/prodtech/cc/articles/about_amd64_abi.html
> http://devrsrc1.external.hp.com/STK/wellbehavedrestrict.html
>
> So we should at least check ALIGNOF_LONG as well.
>
> (3)
> There are some machines with sizeof(int) equals to 64, if my memory saves,
> which might imply that ALIGNOF_INT equals to 8.
sizeof(int) maybe 8, but not 64.
And the configure option `--enable-integer-datetimes' may affect the data
layout.
>
> So conservatively, we'd better check ALIGNOF_INT, ALIGNOF_LONG and
> MAXIMUM_ALIGNOF.
>
> Regards,
> Qingqing
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-09-28 15:25:07 | Re: [PATCHES] Proposed patch for sequence-renaming problems |
Previous Message | Tom Lane | 2005-09-28 15:09:45 | Re: Proposed patch for sequence-renaming problems |