kgrittn@dtr2:~/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

kgrittn@dtr2:~/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
kgrittn@dtr2:~/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 <tgl@sss.pgh.pa.us> 10/12/05 10:10 AM >>>
Alvaro Herrera <alvherre@alvh.no-ip.org> 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