Re: Random crashes - segmentation fault

Поиск
Список
Период
Сортировка
От kjonca@fastmail.com (Kamil Jońca)
Тема Re: Random crashes - segmentation fault
Дата
Msg-id 87tv77digm.fsf@alfa.kjonca
обсуждение исходный текст
Ответ на Re: Random crashes - segmentation fault  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Random crashes - segmentation fault  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes:

> On Wed, Nov 13, 2019 at 09:12:02AM +0100, Kamil Jońca wrote:
>> Today (13.XI.2019 - KJ)  was another crash.
>> Another piece of a puzzle: There is (unlogged) table with 70M+
>> rows. After crash this table is empty (but table itself exists.)
>
> Could it be possible to see a backtrace of the crash?  There is

Erm. Only thing I can do is to configure for debug future crashes. Could you
tell me what and how to configure to get backtrace?
This is debian sid machine with postgres packaged by debian folks.
I guess I should enable core dumps. Anything else?

> nothing we can really do without any hint.  If you can send a
> self-contained test case which allows to reproduce the problem, that's
> even better.
I am afraid I cannot. These crasheas are rather rare and unpredictable.

> Please note that unlogged tables are reinitialized after
> a crash at the beginning of recovery.  That's their design.
I see. Thanks for explanation.

KJ


--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
If I have trouble installing Linux, something is wrong. Very wrong.
        -- Linus Torvalds



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Random crashes - segmentation fault
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: 回复: BUG #16101: tables in theDB is not available after pg_restore