Re: Fwd: 8.1beta2 vacuum analyze hanging on idle database

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> The software we are running is a build from the beta2 release, with
> no special options specified at ./configure time. Would you expect
> such a build to include the debug info you wanted?

No, you need configure --enable-debug, which is not the default.
For working with a beta release, --enable-cassert isn't a bad idea
either, though it is probably not relevant to your problem.

> (gdb) bt
> #0 0x40197b46 in recv () from /lib/i686/libc.so.6
> #1 0x0813485f in secure_read ()
> #2 0x08138f7b in pq_recvbuf ()
> #3 0x081393a9 in pq_getbyte ()
> #4 0x08195565 in PostgresMain ()
> #5 0x081716c5 in ServerLoop ()
> #6 0x0817232e in PostmasterMain ()
> #7 0x0813aad8 in main ()

> Which seemed to show reasonable information, to my untrained eye.

Yeah, that looks expected for a non-debug build. (Debug build would
show call parameters too, which is why it would be more helpful
even apart from the "(corrupt stack?)" problem.)

> That got me wondering whether the "(corrupt stack?)" note on the
> previous backtrace might be something real.

More likely, it's specific to particular places in the code that got
optimized in a way that gdb couldn't figure out.

regards, tom lane