On Sat, 2007-12-08 at 02:46 -0500, Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > We could always tighten this up a bit by listing the alignment of a
> > handful of built-in data types but I suppose there will always be
> > holes in this area anyways.
>
> In theory yeah, but the note in pg_control.h still applies to every
> platform I've heard of:
>
> * This data is used to check for hardware-architecture compatibility of
> * the database and the backend executable. We need not check endianness
> * explicitly, since the pg_control version will surely look wrong to a
> * machine of different endianness, but we do need to worry about MAXALIGN
> * and floating-point format. (Note: storage layout nominally also
> * depends on SHORTALIGN and INTALIGN, but in practice these are the same
> * on all architectures of interest.)
>
> The main risk we are taking is in the assumption that int64 and float8
> have the same alignment requirement, ie DOUBLEALIGN. Which is probably
> a fairly safe thing in reality. Also, we've so far avoided using either
> type in the system catalogs, which takes away one of the possible
> failure modes (that the C compiler's alignment of struct fields might
> vary from what we think the type needs).
Sounds like Josh is asking for a way to find out the things that matter
on an architecture and compare them with the relevant parts of the
pg_control structure. The 32/64 bit thing was probably just his
shorthand for that. Perhaps we should document how to perform a
portability check?
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
