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: Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Built-in support for a memory consumption ulimit?
Date: 2014-06-18 07:13:15
Message-ID: CAA4eK1Ju1VSECBQfOcqMfJ_1UBK-vcSqL7snuFz31QOMdMk_bQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 18, 2014 at 10:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > Won't it be possible if we convert malloc calls in backend code to
> > go through wrapper, we already have some precedents of same like
> > guc_malloc, pg_malloc?
>
> We do not have control over mallocs done by third-party code
> (think pl/perl for example).

Yeah, mallocs done by third-party code would be difficult to track,
one possibility could be that we expose a built-in memory allocator
function. I think it will lead to change in third-party code who wants
to use this new feature. However if thats not viable then we need to
think about some OS specific calls like the one you have suggested
above (sbrk(0)), but I think that solution might also need to have
portable API for Windows.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-06-18 07:30:06 include_dir catch-22
Previous Message Mitsumasa KONDO 2014-06-18 05:44:25 Re: gaussian distribution pgbench