| From: | kjonca(at)fastmail(dot)com (Kamil Jońca ) |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Random crashes - segmentation fault |
| Date: | 2019-11-13 13:16:57 |
| Message-ID: | 87tv77digm.fsf@alfa.kjonca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-11-13 13:30:29 | Re: 回复： BUG #16101: tables in the DB is not available after pg_restore |
| Previous Message | Michael Paquier | 2019-11-13 12:58:32 | Re: Random crashes - segmentation fault |