Subject: pg_controldata doesn't report 64/32bit?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/7/2007 10:00:27 PM
Josh Berkus <josh@agliodbs.com> writes:
> I've just noticed that pg_controldata doesn't say anything about whether
> the database is 64-bit or 32-bit.
That's because there is no such concept.
> Since the data files can be
> incompatible based on word length, shouldn't that be in pg_controldata?
They can't be incompatible "based on word length". They can be
incompatible based on MAXALIGN ... which *is* reported.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Subject: pg_controldata doesn't report 64/32bit?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/8/2007 2:37:52 AM
Gregory Stark <stark@enterprisedb.com> writes:
> Argh, As soon as I sent it I realized even that's not right. The
> alignments of our datums is specified by pg_type and doesn't vary by
> platform. There has been some thought of making 8-byte data types like
> bigint pass-by-value on 64-bit machines in which case we would want to
> put that boolean flag in the control file as well.
And that's *still* not right, because whether a type is pass-by-value
has again got exactly 0 to do with what the bits look like on disk.
The only 32-vs-64-bit difference that has any impact on the on-disk
layout is MAXALIGN, which tends to be different in the two cases
(though there are exceptions).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Subject: pg_controldata doesn't report 64/32bit?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/8/2007 2:46:21 AM
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).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|