From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
Cc: | Valentine Gogichashvili <valgog(at)gmail(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion |
Date: | 2013-10-21 14:47:26 |
Message-ID: | 20131021144726.GF2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
* Frank van Vugt (ftm(dot)van(dot)vugt(at)foxi(dot)nl) wrote:
> Op zaterdag 19 oktober 2013 21:02:25 schreef Valentine Gogichashvili:
> > this is a little bit not relevant to the question itself. But to prevent OOM
> > killer from currupting your database please consider this for your
> > production environments:
>
> Sure, I understand why you'd want to mention this 'on the side', but I'm aware
> of OOM-tuning. In production, I use it wherever it's _really_ needed, but mind
> that the oom-killer in newer kernels is already selecting processes a bit
> smarter than it used to. In the example I gave, the correct child process was
> killed.
The correct child being killed doesn't actually mean that it's a *good
idea* to kill off PG child processes, in general, particularly in the
way that the OOM killer goes about it (kill -9). If it was possible to
tune the OOM killer to use a different signal, which would allow PG to
actually clean things up, it *might* be reasonable to allow it, but I
still wouldn't recommend it.
In production, for my part, proper memory accounting (and disabling of
OOM) should *always* be used.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-10-21 15:14:06 | Re: random() generates collisions too early |
Previous Message | alfonso.vicente | 2013-10-21 14:31:39 | BUG #8543: Standby recovery use incorrect timeline to determine WAL length |