Bill Moran writes:
> Tom Lane wrote:
>> Bill Moran wrote:
>>> What I feel is the best way to mitigate the situation, is to have some
>>> setting that limits the maximum RAM any backend can consume.
>> I've had some success using ulimit in the past,
> Hopefully having this in the list archives w
On Wed, 08 Feb 2017 10:44:24 -0500
Tom Lane wrote:
> Albe Laurenz writes:
> > Bill Moran wrote:
> >> What I feel is the best way to mitigate the situation, is to have some
> >> setting that limits the maximum RAM any backend can consume.
>
> > I'd delegate that problem to the operating system w
On Wed, Feb 8, 2017 at 7:44 AM, Tom Lane wrote:
> Albe Laurenz writes:
> > Bill Moran wrote:
> >> What I feel is the best way to mitigate the situation, is to have some
> >> setting that limits the maximum RAM any backend can consume.
>
> > I'd delegate that problem to the operating system which
Albe Laurenz writes:
> Bill Moran wrote:
>> What I feel is the best way to mitigate the situation, is to have some
>> setting that limits the maximum RAM any backend can consume.
> I'd delegate that problem to the operating system which, after all,
> should know best of all how much memory a proc
Bill Moran wrote:
> If you run a transaction with lots of server side functions that use a
> lot of memory, this can trigger the OOM killer in Linux, causing the
> PosgreSQL backend to receive a SIGKILL and all the associated bad
> stuff.
>
> Tuning the OOM killer is not sufficient. No setting I'v
