Re: [SPAM] psql 9.3 automatic recovery in progress - Mailing list pgsql-general

From Tom Lane
Subject Re: [SPAM] psql 9.3 automatic recovery in progress
Date
Msg-id 17622.1476137710@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SPAM] psql 9.3 automatic recovery in progress  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: [SPAM] psql 9.3 automatic recovery in progress
List pgsql-general
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 10/10/2016 12:18 PM, Periko Support wrote:
>> I was on vacation, but the issue have the same behavior:

> Actually no. Before you had:

> 2016-09-12 09:00:01 PDT LOG:  server process (PID 23958) was
> terminated by signal 9: Killed

> Now you have:

> 2016-10-10 07:50:09 PDT WARNING:  terminating connection because of
> crash of another server process

Most likely it *is* the same thing but the OP trimmed the second log
excerpt too much.  The "crash of another server process" complaints
suggest strongly that there was already another problem and this
is just part of the postmaster's kill-all-children-and-restart
recovery procedure.

Now, if there really is nothing before this in the log, another possible
theory is that something decided to send the child processes a SIGQUIT
signal, which would cause them to believe that the postmaster had told
them to commit hara-kiri.  I only bring this up because we were already
shown a script sending random SIGKILLs ... so random SIGQUITs wouldn't be
too hard to credit either.  But the subsequent log entries don't quite
square with that idea; if the postmaster weren't already expecting the
children to die, it would have reacted differently.

            regards, tom lane


pgsql-general by date:

Previous
From: Periko Support
Date:
Subject: Re: [SPAM] psql 9.3 automatic recovery in progress
Next
From: Tom Lane
Date:
Subject: Re: LOG: munmap(0x7fff80000000) failed: Invalid argument