Re: Built-in support for a memory consumption ulimit? - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Built-in support for a memory consumption ulimit?
Date
Msg-id CAA4eK1+sPoRkJAhGJ6s3h0Phn94o+Hc8Fqvpvi2e4nywxa5+yg@mail.gmail.com
Whole thread Raw
In response to Built-in support for a memory consumption ulimit?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Built-in support for a memory consumption ulimit?  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Sat, Jun 14, 2014 at 8:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> After giving somebody advice, for the Nth time, to install a
> memory-consumption ulimit instead of leaving his database to the tender
> mercies of the Linux OOM killer, it occurred to me to wonder why we don't
> provide a built-in feature for that, comparable to the "ulimit -c max"
> option that already exists in pg_ctl.

Considering that we have quite some stuff which is backend local (prepared
statement cache, pl compiled body cache, etc..) due to which memory
usage can increase and keep on increasing depending on operations
performed by user or due to some bug, I think having such a feature will be
useful.  Infact I have heard about such complaints from users.

> A reasonably low-overhead way
> to do that would be to define it as something a backend process sets
> once at startup, if told to by a GUC.  The GUC could possibly be
> PGC_BACKEND level though I'm not sure if we want unprivileged users
> messing with it.

Providing such a feature via GUC is a good idea, but I think changing
limit for usage of system resources should be allowed to privileged
users.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL replay bugs
Next
From: Stephen Frost
Date:
Subject: Re: API change advice: Passing plan invalidation info from the rewriter into the planner?