Re: [SPAM] psql 9.3 automatic recovery in progress

From: Periko Support <pheriko(dot)support(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: [SPAM] psql 9.3 automatic recovery in progress
Date: 2016-10-11 00:45:55
Message-ID: CAK2yrTa-U3EQMm+Ke7PoOEXRpA6tWaO_BbQJhKuULChaiQZz7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott your script is very clean, I'm testing, thanks.

On Mon, Oct 10, 2016 at 3:28 PM, Scott Mead <scottm(at)openscg(dot)com> wrote:
>
>
> On Mon, Oct 10, 2016 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>
>
>
> --
> --
> Scott Mead
> Sr. Architect
> OpenSCG
> http://openscg.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2016-10-11 01:50:17 Re: psql 9.3 automatic recovery in progress
Previous Message Tom Lane 2016-10-11 00:45:40 Re: LOG: munmap(0x7fff80000000) failed: Invalid argument