On 18/01/2008, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> "Dave Page" <dpage@xxxxxxxxxxxxxx> writes:
> > Note to the other hackers - is it worth having initdb dump the
> > architecture details and configure options used into the cluster in a
> > human readble form so we can pickup on this sort of thing more easily
> > in the future?
>
> 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.
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'
--------
in a file in $PGDATA which would make it much easier for users and
hackers to see where the cluster came from and compare it to the
actual build.
/D
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
