Re: BUG #1015: Got a signal 11 while trying to create a temp table - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #1015: Got a signal 11 while trying to create a temp table
Date
Msg-id 17304.1071941241@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #1015: Got a signal 11 while trying to create a temp table  ("aarjan langereis" <a.j.langereis@inter.nl.net>)
List pgsql-bugs
"aarjan langereis" <a.j.langereis@inter.nl.net> writes:
> How do I get a "debugger backtrace" ?

Find the "core" file left by the crashed backend --- it should be in
$PGDATA/base/yourdbnumber/core and have a file date equal to the time
of the crash.  If you don't find one, it's likely that the postmaster
was started under "ulimit -c 0" which prevents core dumps.  Restart
the postmaster under "ulimit -c unlimited" and reproduce the crash.

Once you have the core file, do
    $ gdb /path/to/postgres-executable /path/to/core-file
    gdb> bt
    gdb> quit

If bt just produces a list of numbers without any names, it's not going
to be helpful.  In that case you need to rebuild Postgres with debugging
symbols and start over.

There is more info in the archives.


> Selecting all data from the tables involved, does that also include a 'coun=
> t(*)', if so, they work:

Mmm, that really only proves that the page headers and tuple headers are
OK, not that there is not data corruption within some row, because
COUNT(*) won't try to extract any field values from any rows.  I'd
suggest a SELECT * or COPY TO FILE operation to check whether there is
any data corruption.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "aarjan langereis"
Date:
Subject: Fw: BUG #1015: Got a signal 11 while trying to create a temp table
Next
From: Tom Lane
Date:
Subject: Re: BUG #1021: IDENT authorization doesn't work