Re: Limiting memory allocation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Limiting memory allocation
Date: 2022-05-17 22:36:15
Message-ID: 1631789.1652826975@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> On Tue, May 17, 2022 at 18:12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ulimit might be interesting to check into as well. The last time I
>> looked, it wasn't too helpful for this on Linux, but that was years ago.

> Unfortunately I really don’t think anything here has materially changed in
> a way which would help us. This would also apply across all of PG’s
> processes and I would think it’d be nice to differentiate between user
> backends running away and sucking up a ton of memory vs backend processes
> that shouldn’t be constrained in this way.

It may well be that they've not fixed its shortcomings, but the claim
that it couldn't be applied selectively is nonsense. See setrlimit(2),
which we already use successfully (AFAIK) to set stack space on a
per-process basis.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2022-05-17 22:52:30 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Previous Message Stephen Frost 2022-05-17 22:30:42 Re: Limiting memory allocation