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