Re: Built-in support for a memory consumption ulimit?

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Built-in support for a memory consumption ulimit?
Date: 2014-06-16 03:56:54
Message-ID: CAA4eK1+sPoRkJAhGJ6s3h0Phn94o+Hc8Fqvpvi2e4nywxa5+yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 14, 2014 at 8:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-06-16 04:24:16 Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Previous Message Michael Paquier 2014-06-16 03:19:12 Re: WAL replay bugs