Re: database crash during pgbench run

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Clough <Greg(dot)Clough(at)ihsmarkit(dot)com>, Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: database crash during pgbench run
Date: 2018-12-21 13:40:25
Message-ID: CAHyXU0xj0Bhm1fM-w=hkjefHmKbD4jrtriWUaQomQvx_+w_gJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Dec 11, 2018 at 10:01 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Greg Clough <Greg(dot)Clough(at)ihsmarkit(dot)com> writes:
> >>> 2018-12-10 19:11:56 IST 23647 LOG: received fast shutdown request
> >>> any idea what can cause it ?
>
> >> Something sent SIGINT to the postmaster.
>
> > My money is on the OoM (Out of Memory) killer.
>
> That usually uses SIGKILL. If I had to guess, I'd wonder whether the
> postmaster was manually started, and if so whether it was properly
> dissociated from the user's terminal (with nohup or the like).
> If it wasn't, then a control-C typed at the terminal would SIGINT the
> postmaster as well as whatever it was meant to terminate.

Yeah. To add to this, pgbench runs are extremely unlikely to cause
the kind of memory consumption issues that would trigger an OOM. This
is definitely not a database crash, just some kind of administrative
problem. Some things that might be helpful to help figure this out:
*) What o/s
*) how was the database installed
*) how exactly did the database start
*) are we looking at something exotic here (cloud managed postgres,
exotic storage, etc)

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message DJ Coertzen 2018-12-21 19:08:33 psql cli tool and connection pooling
Previous Message Merlin Moncure 2018-12-20 16:46:42 Re: pgbench results arent accurate