Обсуждение: pg_controldata doesn't report 64/32bit?
Folks, I've just noticed that pg_controldata doesn't say anything about whether the database is 64-bit or 32-bit. Since the data files can be incompatible based on word length, shouldn't that be in pg_controldata? --Josh Berkus
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
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > 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. I think the relevant concept is whether Datum is 32-bit or 64-bit wide. My first thought was that surely the structure would be massively different on a 64-bit architecture though? But actually I'm not sure that's true. There's an Oid in the checkpoint record which is an "unsigned int" so at least ILP64 architectures would be distinguished but I can't find any "long" members or pointers so an LP64 architecture actually would have the same member sizes as a 32-bit architecture. So if there's an LP64 architecture which has the same maxalign (presumably 64-bit for doubles) as its 32-bit cousin then it's actually possible we wouldn't notice? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
"Gregory Stark" <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > >> 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. > > I think the relevant concept is whether Datum is 32-bit or 64-bit wide. Oh, I see what you meant now. Datum is a purely in-memory concept, it doesn't actually reach disk. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
"Gregory Stark" <stark@enterprisedb.com> writes: > Oh, I see what you meant now. Datum is a purely in-memory concept, it doesn't > actually reach disk. > > 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. 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. But until that happens there's nothing to see here. Sorry for the noise arguing with myself. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
Gregory Stark wrote: > "Gregory Stark" <stark@enterprisedb.com> writes: > >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> >>> 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. >> I think the relevant concept is whether Datum is 32-bit or 64-bit wide. > > Oh, I see what you meant now. Datum is a purely in-memory concept, it doesn't > actually reach disk. > > 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. What are we gaining here? A 32bit postmaster can't start a 64bit one... Running select version() will tell you if you are running 64 or 32bit... What am I missing? Joshua D. Drake > >
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
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 *
machineof different endianness, but we do need to worry about MAXALIGN * and floating-point format. (Note: storage
layoutnominally also * depends on SHORTALIGN and INTALIGN, but in practice these are the same * on all
architecturesof 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
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
Simon, > 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? > Pretty much. We're supporting x86 64-bit servers for Solaris now, and we need SMF to be able to check whether it can safely run x binaries against y data. --Josh Berkus
Am Samstag, 8. Dezember 2007 schrieb Josh Berkus: > Pretty much. We're supporting x86 64-bit servers for Solaris now, and > we need SMF to be able to check whether it can safely run x binaries > against y data. Well, the canonical way to do that is to start the server and see if it succeeds. You might get an indication that it will not work by running pg_controldata. But that is probably not a sufficient check. -- Peter Eisentraut http://developer.postgresql.org/~petere/