From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Josh Berkus" <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_controldata doesn't report 64/32bit? |
Date: | 2007-12-08 07:46:21 |
Message-ID: | 5109.1197099981@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)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).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-12-08 08:54:30 | Re: pg_controldata doesn't report 64/32bit? |
Previous Message | Tom Lane | 2007-12-08 07:37:52 | Re: pg_controldata doesn't report 64/32bit? |