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
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 |