Group: pgsql.hackers


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