Re: What to do when dynamic shared memory control segment is corrupt - Mailing list pgsql-general

From Andres Freund
Subject Re: What to do when dynamic shared memory control segment is corrupt
Date
Msg-id 20180618172843.v2wfdq3xzuwfnzqb@alap3.anarazel.de
Whole thread Raw
In response to Re: What to do when dynamic shared memory control segment is corrupt  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: What to do when dynamic shared memory control segment is corrupt  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 2018-06-18 12:30:13 -0400, Tom Lane wrote:
> Sherrylyn Branchaw <sbranchaw@gmail.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


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: What to do when dynamic shared memory control segment is corrupt
Next
From: Robert Creager
Date:
Subject: Re: Query hitting empty tables taking 48 minutes