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

From Tom Lane
Subject Re: Built-in support for a memory consumption ulimit?
Date
Msg-id 12773.1403037591@sss.pgh.pa.us
Whole thread Raw
In response to Re: Built-in support for a memory consumption ulimit?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Built-in support for a memory consumption ulimit?  (Robert Haas <robertmhaas@gmail.com>)
Re: Built-in support for a memory consumption ulimit?  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Built-in support for a memory consumption ulimit?  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> We could do better by accounting for memory usage ourselves, inside
> the memory-context system, but that'd probably impose some overhead we
> don't have today.

Hm.  We could minimize the overhead if we just accounted for entire
malloc chunks and not individual palloc allocations.  That would make
the overhead not zero, but yet probably small enough to ignore.

On the other hand, this approach would entirely fail to account for
non-palloc'd allocations, which could be a significant issue in some
contexts.

I wonder how practical it would be to forestall Noah's scenario by
preallocating all the stack space we want before enabling the rlimit.

Another idea would be to do the enforcement ourselves by means of
measuring the change in "sbrk(0)"'s reported value since startup, which we
could check whenever, say, we're about to request a large malloc chunk in
aset.c.  I'm not sure about the cost of that function though, nor about
whether this measurement method is meaningful in modern systems.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Robert Haas
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()