Re: Core dumps, i.e. how to track down a problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Core dumps, i.e. how to track down a problem
Дата
Msg-id 5036.974852219@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Core dumps, i.e. how to track down a problem  (oberpwd@anubis.network.com (Wade D. Oberpriller))
Список pgsql-general
oberpwd@anubis.network.com (Wade D. Oberpriller) writes:
> Whenever I try to execute one of these functions, the postgres server
> process crashes. Does this process leave a core dump or some kind of
> trace to be able to learn more about what is happening?  All it does
> now is report that the server process aborted with a status 11.

There should be a core file in the database subdirectory
($PGDATA/base/yourdbname/core).  If you don't find one there, the
odds are that you started the postmaster with "ulimit -c 0" which
prevents coredumps.  (Unfortunately, on some platforms this is the
default environment for anything started from a boot script.)  Restart
the postmaster with "ulimit -c unlimited" and try again.

Once you have the core file, use gdb to get a backtrace:

    gdb /path/to/postgres/executable /path/to/corefile
    bt
    quit

> Is there any extra flags to turn on, or compile with that could help?

The corefile will be more informative if you compiled with -g, but
a backtrace may be useful even without.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: oberpwd@anubis.network.com (Wade D. Oberpriller)
Дата:
Сообщение: Core dumps, i.e. how to track down a problem
Следующее
От: Patrick Robin
Дата:
Сообщение: backend dies when a user defined type returns null