Re: BUG #6200: standby bad memory allocations on SELECT

On Sat, Jan 28, 2012 at 8:45 PM, Michael Brauwerman
<michael(dot)brauwerman(at)redfin(dot)com> wrote:
> We did try that with a postgres 9.1.2, compiled from source with debug
> flags, but we got 0x10 bad address in gdb. (Obviously we did it wrong
> somehow)
>
> We will keep trying to get a good set of symbols set up.

Hmm. Your backtrace is, on the one hand, unsurprising - because I
don't have complete confidence that nocachegetattr won't index off
into oblivion given corrupt data on disk - and on the other hand,
unconvincing, mostly because of this:

warning: core file may not match specified executable file.

If you're doing a custom build, it should be enough to use
--enable-debug and then gdb the core file with the path to the
executable you built. If you're using Red Hat, you can just do
debuginfo-install package-name, where package-name is probably
something like "postgresql-server". But either way, it's critical
that the executable you use to pull the backtrace be exactly the same
one that was running when the system went belly-up, and it's hard to
be confident that's the case here.

All that having been said, it *is* possible, even if you do everything
right, to run across a situation where gdb can't extract a backtrace.
This mostly commonly happens at higher optimization levels. You might
want to try building -fno-omit-frame-pointer or even -O0 to minimize
the chances of the compiler doing something that's too clever for gdb.
If you do manage to get it working correctly, the backtrace should
show not only ALL (rather than only some) functions in the call stack
but also the values of the arguments passed to each of those
functions, which, probably needless to say, would be awfully helpful
in figuring this one out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company