Kelly Burkhart <kelly.burkhart@xxxxxxxxx> writes: > RE: stripped symbols, I assume you mean configuring with > --enable-debug specified, I see from my config.log that I did not > specify that flag. Ah, if you built it yourself, that explains why your sysadmins' installation of symbol packages didn't help. If you're building with gcc, --enable-debug is pretty much always a good idea: it doesn't cost anything but some extra disk space. With some other compilers --enable-debug disables optimization and hence isn't a good idea for production builds. > I just built with debug symbols on a > non-production machine and the stack trace is different. I assume > it's completely invalid because symbol addresses from different builds > are not guaranteed to line up. Correct? Or is this helpful? Again, depends if it's gcc. If so, and everything is identical between this machine and the one where you did the original build, this'd probably work. > Program terminated with signal 11, Segmentation fault. > #0 0x000000000068d884 in RelationCacheInitializePhase2 () at relcache.c:2588 > 2588 LOAD_CRIT_INDEX(IndexRelidIndexId); That looks interesting, indeed. I don't think I want to trust it entirely because of the likelihood that there's some difference between this build and the original; but if it's not too far off from reality then it places the failure in relcache.c rather than SearchCatCacheList. And that makes sense because we have indeed fixed several cache-related bugs in relcache over the past six months or so. At this point I'd *strongly* encourage you to update to 8.4.4. And please do build with --enable-debug in future, if you're using gcc. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
