[EMAIL PROTECTED]:~/postgresql-snapshot> /usr/local/pgsql/bin/pg_config BINDIR = /usr/local/pgsql/bin DOCDIR = /usr/local/pgsql/doc INCLUDEDIR = /usr/local/pgsql/include PKGINCLUDEDIR = /usr/local/pgsql/include INCLUDEDIR-SERVER = /usr/local/pgsql/include/server LIBDIR = /usr/local/pgsql/lib PKGLIBDIR = /usr/local/pgsql/lib LOCALEDIR = MANDIR = /usr/local/pgsql/man SHAREDIR = /usr/local/pgsql/share SYSCONFDIR = /usr/local/pgsql/etc PGXS = /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--enable-debug' '--enable-cassert' CC = gcc CPPFLAGS = -D_GNU_SOURCE CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,/usr/local/pgsql/lib LDFLAGS_SL = LIBS = -lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm VERSION = PostgreSQL 8.1beta2
This was built from a devel snapshot last Thursday morning: -rw-r--r-- 1 kgrittn users 14354223 2005-10-06 09:56 postgresql-snapshot.tar.gz [EMAIL PROTECTED]:~/postgresql-snapshot/src/backend/storage/buffer> rm bufmgr.o; make rm: remove write-protected regular file `bufmgr.o'? yes gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g -I../../../../src/include -D_GNU_SOURCE -c -o bufmgr.o bufmgr.c /usr/i586-suse-linux/bin/ld -r -o SUBSYS.o buf_table.o buf_init.o bufmgr.o freelist.o localbuf.o [EMAIL PROTECTED]:~/postgresql-snapshot/src/backend/storage/buffer> grep \$PostgreSQL bufmgr.c * $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.195 2005/08/12 23:13:54 momjian Exp $ bufmgr.s file coming in separate (off-list) email. >>> Tom Lane <[EMAIL PROTECTED]> 10/12/05 10:10 AM >>> Alvaro Herrera <[EMAIL PROTECTED]> writes: > Kevin Grittner wrote: >> I'm not sure what you mean regarding pg_config -- could you clarify? > The output of pg_config --configure Actually I wanted the whole thing, not just --configure (I'm particularly interested in the CFLAGS setting). >> Your email came through as I was trying to figure out where to find >> the core dump. We restarted the server with cassert, and I find this >> in the log prior to my attempt to vacuum: > It should be in $PGDATA/core (maybe with some other name depending on > settings) If my theory about a bogus increment code sequence is correct, then the core dump will not tell us anything very interesting anyway --- the trap will happen when the slower of the two processes tries to remove its pin, but that's way after the bug happened. I'm thinking that the easiest way to confirm or disprove this theory is to examine the assembly code. Please do this: 1. cd into src/backend/storage/buffer directory of build tree. 2. rm bufmgr.o; make 3. Note gcc command issued by make to rebuild bufmgr.o. Cut and paste, changing -c to -S and removing "-o bufmgr.o" if present. Keep all the other switches the same. 4. This should produce a file bufmgr.s. Gzip and send to me (off-list please, it's likely to be large and boring) Please also confirm exactly which version of bufmgr.c you are working with --- the $PostgreSQL line near the head of the file will do. regards, tom lane ---------------------------(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