On Mon, Oct 10, 2016 at 6:15 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
