Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jun 14, 2014 at 10:37 AM, 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. 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.
> What happens if the limit is exceeded? ERROR? FATAL? PANIC?
We'd presumably get NULL returns from malloc, which'd be reported
as elog(ERROR, "out of memory"). It's not anything new for the
code to handle.
One issue if we allow this to be set on something other than PGC_BACKEND
timing is that somebody might try to reduce the setting to less than his
session is currently using. I'm not sure what setrlimit would do in
such cases --- possibly fail, or maybe just set a limit that would cause
all subsequent malloc's to fail. I doubt it'd actually take away existing
memory though.
regards, tom lane
