Hi,
> On 18. May 2022, at 17:11, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-May-18, Jan Wieck wrote:
>
>> Maybe I'm missing something, but what is it that you would actually consider
>> a solution? Knowing your current memory consumption doesn't make the need
>> for allocating some right now go away. What do you envision the response of
>> PostgreSQL to be if we had that information about resource pressure?
>
>
> What they (Timescale) do, is have a LD_PRELOAD library that checks
> status of memory pressure, and return NULL from malloc(). This then
> leads to clean abort of transactions and all is well. There's nothing
> that Postgres needs to do different than today.
Correct. The library we have reads a limit supplied in an environment variable
and stores per-process and total memory usage values in shared memory counters,
updated after each call to malloc/free/calloc/realloc by the process making the
call. When updating totals, a process picks one of N counters to update
atomically with the difference between its old and new memory usage, avoiding
congested ones; those are summed to determine current allocations for all
processes and to compare against the limit.
>
> I suppose that what they would like, is a way to inquire into the memory
> pressure status at MemoryContextAlloc() time and return NULL if it is
> too high.
If we call user code just before malloc (and, presumably free and realloc), the
code would have to do just as much work as when it is called from the
malloc/free/realloc wrappers inside a preloaded library. Furthermore, I don’t
see why the user would want to customize that logic: a single Linux-specific
implementation would solve the problem for everyone.
> How exactly this would work is unclear to me; maybe one
> process keeps an eye on it in an OS-specific manner,
We don’t need to do anything for non-Linux systems, as cgroups and OOM
killer doesn’t exist there.
> and if it does get
> near the maximum, set a bit in shared memory that other processes can
> examine when MemoryContextAlloc is called. It doesn't have to be
> exactly accurate; an approximation is probably okay.
What would be a purpose of setting a bit in shared memory when the maximum Is
about to be reached?
What would be useful is a way for Postgres to count the amount of memory
allocated by each backend. This could be advantageous for giving per-backend
memory usage to the user, as well as for enforcing a limit on the total amount
of memory allocated by the backends.
—
Oleksii Kliukin