[PostgreSQL-Hackers] Re: Database file compatability

""Jim C. Nasby"" <[email protected]> wrote
The key problem I believe is the serials of ALIGNOF macros. Especially for
MAX_ALIGNOF. Different Hardware/OS/compiler will have different
understanding of it. Compare your two versions PG, if they match, then with
big chance, you can exchange their data.
Undefined. Mostly core dump.

Regards,
Qingqing

Yeah. It might be worth adding MAX_ALIGNOF to the set of configuration
data stored in pg_control, just to be sure you couldn't shoot yourself
in the foot that way.

regards, tom lane

PLEASE. :)

ISTM that 64 bit is becomming much more common, so I think the odds of
someone going from a 32 to 64 bit (or vice-versa) version of PostgreSQL
on the same machine is much larger now than it has been in the past. I
think we really need to protect this as much as possible. This isn't so
much a foot-gun as a foot-nuclear-weapon.

Would I be correct in assuming that doing this for 8.1 would require
another initdb? :/ For something as minor as this, would it be
reasonable to ship a utility to avoid the initdb? I'd very much like to
see this in 8.1...

""Jim C. Nasby"" <[email protected]> wrote
I am coming up with a patch of it. I think all ALIGNOF macros should be
checked.

Regards,
Qingqing

There are no platforms for which ALIGNOF_SHORT is different from 2.
I don't think there are any platforms we care about where ALIGNOF_INT
is different from 4. The cases of interest are ALIGNOF_DOUBLE,
ALIGNOF_LONG, ALIGNOF_LONG_LONG_INT (note that MAXIMUM_ALIGNOF is
just the largest of these). In practice "long int" is the same type
as either "int" or "long long int", so ALIGNOF_LONG isn't a distinct
case either. What it comes down to is that MAXIMUM_ALIGNOF is
sufficient to tell the difference between the platforms we need to
deal with. If you have a counterexample, tell us about it.

regards, tom lane

"Tom Lane" <[email protected]> wrote in message
news:[email protected]...
(1)
Yes, ALIGNOF_SHORT is always 2.

(2)
There is a possible sequence like this:

ALIGNOF_LONG 4
ALIGNOF_DOUBLE 8
MAXIMUM_ALIGNOF 8

vs.

ALIGNOF_LONG 8
ALIGNOF_DOUBLE 8
MAXIMUM_ALIGNOF 8

Eg.
http://developers.sun.com/prodtech/cc/articles/about_amd64_abi.html
http://devrsrc1.external.hp.com/STK/wellbehavedrestrict.html

So we should at least check ALIGNOF_LONG as well.

(3)
There are some machines with sizeof(int) equals to 64, if my memory saves,
which might imply that ALIGNOF_INT equals to 8.

So conservatively, we'd better check ALIGNOF_INT, ALIGNOF_LONG and
MAXIMUM_ALIGNOF.

Regards,
Qingqing

No, we don't need to, because we do not really care about ALIGNOF_LONG
per se. We don't use "long" as an on-disk datatype, precisely because
we don't know what size it is. We use int32 and int64. The former has
align 4 on all machines AFAIK, and the latter has MAXIMUM_ALIGNOF.
If there were such a machine, Postgres wouldn't run on it anyway, and
a lot of other software too. There'd be no way to have both int16 and
int32 types ("short" could cover only one of them).

regards, tom lane

Is there a serious penalty associated with just checking them all? Seems
like better safe than sorry...

On a related note, are checks for endianness made as well?

"Qingqing Zhou" <[email protected]> wrote
sizeof(int) maybe 8, but not 64.
And the configure option `--enable-integer-datetimes' may affect the data
layout.

"William ZHANG" <[email protected]> wrote >
Yes, typo. This has been checked by ControlFileData.enableIntTimes.

Regards,
Qingqing