Re: BUG #1015: Got a signal 11 while trying to create a temp table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "aarjan langereis" <a(dot)j(dot)langereis(at)inter(dot)nl(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1015: Got a signal 11 while trying to create a temp table
Date: 2003-12-20 17:27:21
Message-ID: 17304.1071941241@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"aarjan langereis" <a(dot)j(dot)langereis(at)inter(dot)nl(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-12-20 18:26:05 Re: BUG #1021: IDENT authorization doesn't work
Previous Message aarjan langereis 2003-12-20 14:19:08 Fw: BUG #1015: Got a signal 11 while trying to create a temp table