Re: [SPAM] psql 9.3 automatic recovery in progress

Поиск
Список
Период
Сортировка
От Periko Support
Тема Re: [SPAM] psql 9.3 automatic recovery in progress
Дата
Msg-id CAK2yrTa-U3EQMm+Ke7PoOEXRpA6tWaO_BbQJhKuULChaiQZz7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [SPAM] psql 9.3 automatic recovery in progress  (Scott Mead <scottm@openscg.com>)
Список pgsql-general
Scott your script is very clean, I'm testing, thanks.

On Mon, Oct 10, 2016 at 3:28 PM, Scott Mead <scottm@openscg.com> wrote:
>
>
> On Mon, Oct 10, 2016 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> 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.
>
>
>
> The better solution is to do this in one query and more safely:
>
> select pid, usename, datname, pg_terminate_backend(pid)
>    FROM pg_stat_activity
>   WHERE usename = 'openerp'
>        AND  now() - query_start > '15 minutes'::interval;
>
>    This will use the builtin 'pg_terminate_backend for you in one shot.
>
>  --Scott
>
>
>
>>
>>
>>                         regards, tom lane
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>
>
>
> --
> --
> Scott Mead
> Sr. Architect
> OpenSCG
> http://openscg.com


В списке pgsql-general по дате отправления:

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