From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sherrylyn Branchaw <sbranchaw(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: What to do when dynamic shared memory control segment is corrupt |
Date: | 2018-06-18 17:28:43 |
Message-ID: | 20180618172843.v2wfdq3xzuwfnzqb@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2018-06-18 12:30:13 -0400, Tom Lane wrote:
> Sherrylyn Branchaw <sbranchaw(at)gmail(dot)com> writes:
> > We are using Postgres 9.6.8 (planning to upgrade to 9.6.9 soon) on RHEL 6.9.
> > We recently experienced two similar outages on two different prod
> > databases. The error messages from the logs were as follows:
> > LOG: server process (PID 138529) was terminated by signal 6: Aborted
>
> Hm ... were these installations built with --enable-cassert? If not,
> an abort trap seems pretty odd.
PANIC does an abort, so that's not too surprising...
if (elevel >= PANIC)
{
/*
* Serious crash time. Postmaster will observe SIGABRT process exit
* status and kill the other backends too.
*
* XXX: what if we are *in* the postmaster? abort() won't kill our
* children...
*/
fflush(stdout);
fflush(stderr);
abort();
}
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Creager | 2018-06-18 18:20:42 | Re: Query hitting empty tables taking 48 minutes |
Previous Message | Tom Lane | 2018-06-18 16:30:13 | Re: What to do when dynamic shared memory control segment is corrupt |