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
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 |