"Dave Page" <dpage@postgresql.org> writes:
> On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's what pg_control is for. We figured out easily enough that this
>> was an endianness problem; having had "big endian" somewhere in
>> cleartext wouldn't have improved matters.
> It got figured out when someone who knew what they were looking for
> peeked at the byte ordering in a file which for all we knew at the
> time might have been damaged anyway - and the same test wouldn't have
> spotted an integer_datetimes difference for example, something which
> bit Greg & I recently and had us puzzled for a while.
Hm? integer_datetimes is encoded separately and there's a very specific
error message if it's wrong. The case I think you are remembering was
caused by a width-of-time_t discrepancy, which should be fixed but it's
got nothing to do with anything else.
> For just about zero cost we could drop something like:
> --------
> Architecture: Darwin snake 8.11.1 Darwin Kernel Version 8.11.1: Wed
> Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
> Configuration: '--prefix=/usr/local/pgsql83/'
> '--enable-integer-datetimes' '--with-openssl' '--with-perl'
> '--with-python' '--with-tcl' '--without-tk' '--with-bonjour'
> '--with-pam' '--with-krb5' 'CFLAGS=-O -g -arch i386 -arch ppc'
> 'LDFLAGS=-ltcl'
> --------
Zero cost and also zero benefit. The missing piece of information here
was that the executable being used was running under PPC emulation, and
I'll bet money that there would have been nothing in either uname or
pg_config output that would have told us that.
regards, tom lane