Re: Random crashes - segmentation fault - Mailing list pgsql-bugs

From kjonca@fastmail.com (Kamil Jońca)
Subject Re: Random crashes - segmentation fault
Date
Msg-id 87tv77digm.fsf@alfa.kjonca
Whole thread Raw
In response to Re: Random crashes - segmentation fault  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Random crashes - segmentation fault  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Random crashes - segmentation fault
Next
From: Tomas Vondra
Date:
Subject: Re: 回复: BUG #16101: tables in theDB is not available after pg_restore