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

"Kevin Grittner" <Kevin.Grittner@wicourts.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