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: