Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> I've managed to get a backtrace, attached, thanks to Ross J. Reedstrom's
> excellent example from the archives, also attached.
> I'm not sure whether the stack frame shown is corrupt, it seems to just
> loop over and over again. (I got fed up after 400+ frames)
What we've got here is the syscache trying to set up for a search of
cache 18, which I believe is the pg_proc-indexed-on-OID cache.
For that it needs the OID comparison function, "oideq" (OID 184).
It's asking the funcmgr for oideq ... and funcmgr is turning around
and asking the syscache for the pg_proc entry with OID 184. Ooops.
I thought there was an interlock in there to report a useful message if
a syscache got called recursively like this. Have to look at why it's
not working. However, I guess your real problem is that the funcmgr is
failing to find proc OID 184 in its own table of built-in functions.
The reason this isn't a recursion under normal circumstances is that the
comparison functions the syscaches need are all supposed to be hardwired
into fmgr.
My bet is that there is something snafu'd in your generation of
fmgrtab.c from pg_proc.h via Gen_fmgrtab.sh, such that your table of
builtin functions is either empty or corrupt.
Before wasting any additional time on it I'd recommend a make distclean,
cvs update, configure and rebuild from scratch to see if the problem
persists. I changed the Gen_fmgrtab.sh setup last week as part of the
first round of fmgr checkins, and I wouldn't be surprised to find that
you've just gotten burnt by out-of-sync files or some such (eg, a local
file that needs to be rebuilt but is timestamped a bit newer than the
cvs-supplied files it depends on).
If you still see the problem with a virgin build, take a look at
src/backend/utils/Gen_fmgrtab.sh and its output
src/backend/utils/fmgrtab.c to see if you can figure out what's
wrong. Could be that I introduced some kind of portability problem
into Gen_fmgrtab.sh ...
regards, tom lane
