From: | Scott Mead <scottm(at)openscg(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Periko Support <pheriko(dot)support(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [SPAM] psql 9.3 automatic recovery in progress |
Date: | 2016-10-10 22:28:46 |
Message-ID: | CAKq0gvJbhAATc30yTeUcFjK3mGKgvRT2Z+LhzBdTQo-k6TQxSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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>*
http://openscg.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-10-11 00:32:09 | Re: LOG: munmap(0x7fff80000000) failed: Invalid argument |
Previous Message | Tom Lane | 2016-10-10 22:21:48 | Re: LOG: munmap(0x7fff80000000) failed: Invalid argument |