Re: [SPAM] psql 9.3 automatic recovery in progress

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [SPAM] psql 9.3 automatic recovery in progress
Дата
Msg-id 17622.1476137710@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [SPAM] psql 9.3 automatic recovery in progress  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: [SPAM] psql 9.3 automatic recovery in progress  (Scott Mead <scottm@openscg.com>)
Список 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 по дате отправления:

Предыдущее
От: Periko Support
Дата:
Сообщение: Re: [SPAM] psql 9.3 automatic recovery in progress
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LOG: munmap(0x7fff80000000) failed: Invalid argument