At 11:42 AM -0500 11/9/05, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
gdb's 'bt' on one of the core files produces:
#0 0x00138eff in ?? ()
#1 0x0017ec8d in ?? ()
#2 0x00246cd8 in ?? ()
#3 0x00000000 in ?? ()
This looks like you have a "stripped" executable, which is a bit odd
considering you said that you built with --enable-debug. Please
check that the installed executable is what you think it is ...
Hmmm, I've moved all previous (beta, RC) PG base directories and
re-installed 8.1.0 again with --enable-debug and --enable-cassert.
During the make process I saw the cc lines floating past with the -g
option.
The commands were:
$ ./configure --with-perl --with-openssl --enable-thread-safety
--enable-debug --enable-cassert --with-includes=/usr/kerberos/include
$ make -j4
$ sudo make install
$ cp /usr/local/pgsql.old/data /usr/local/pgsql
$ sudo su postgres
$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
$ pkill -ABRT postmaster
This produced a bunch of core files that show the following backtrace:
#0 0x001ea038 in ?? ()
#1 0xbfffa4d8 in ?? ()
#2 0xbfffa5e0 in ?? ()
#3 0xbfffa560 in ?? ()
#4 0x08180844 in ?? ()
#5 0x00000005 in ?? ()
#6 0xbfffa4e0 in ?? ()
#7 0x00000000 in ?? ()
I'm at a loss as to what to do about it, really; is there a hidden
configure flag or something that could be in my environment that's
causing the executable to be stripped? I see various strip related
things within the Makefile, but I definitely didn't make the
install-strip target.
Is there any chance of putting together a self-contained test case
that other people could try?
The simple test case so far is not causing the assertion failure,
perhaps because it is just a simple approximation of the case. At
this point I'm more concerned about getting a non-stripped PG
installed so that should this error or another occur the core file
will have perhaps helpful information.
Thanks in advance for any pointers,
Joel
---------------------------(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
