OK, here's the output:
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x000000000043c82c in heap_modifytuple ()
(gdb)
// not very hopeful, I'd think //
Can I get a RHES/CENTOS PG 8.1 RPM with the symbols enabled? Unfortunately, I
don't think I can give out a dump of the DB (heavily constrained) because of
private customer information... and the query works *FINE* with different
datasets. There's something specific about THIS QUERY that's causing the
failure.
I'm going to try to get this to fail on another system that's not in
production use, though it's a uniprocessor P4.
-Ben
On Wednesday 25 January 2006 07:52, you wrote:
> Benjamin Smith <lists@benjamindsmith.com> writes:
> > What's the best way to do this? Take PG down (normally started as a
service)
> > and run directly in a single-user mode?
>
> No, just start a psql session in one window, then in another window
> determine the PID of the backend process it's connected to, and attach
> gdb to that process. Something like
>
> ps auxww | grep postgres:
> ... eyeball determination of correct PID ...
> gdb /path/to/postgres-executable PID
> gdb> continue
>
> Now, in the psql window, do what's needed to provoke the crash. gdb
> should trap at the instant of the segfault and give you another gdb>
> prompt. Type "bt" to get the backtrace, then "q" to disconnect.
>
> regards, tom lane
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978