On Sat, 2007-12-08 at 02:46 -0500, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
