pg_controldata doesn't report 64/32bit?

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's PostgreSQL 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
* 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

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/