Re: Add the ability to limit the amount of memory that can be allocated to backends.

From: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
To: reid(dot)thompson(at)crunchydata(dot)com, Arne Roland <A(dot)Roland(at)index(dot)de>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, "stephen(dot)frost" <stephen(dot)frost(at)crunchydata(dot)com>
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Date: 2023-10-03 11:33:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 29/9/2023 09:52, Andrei Lepikhov wrote:
> On 22/5/2023 22:59, reid(dot)thompson(at)crunchydata(dot)com wrote:
>> Attach patches updated to master.
>> Pulled from patch 2 back to patch 1 a change that was also pertinent
>> to patch 1.
> +1 to the idea, have doubts on the implementation.
> I have a question. I see the feature triggers ERROR on the exceeding of
> the memory limit. The superior PG_CATCH() section will handle the error.
> As I see, many such sections use memory allocations. What if some
> routine, like the CopyErrorData(), exceeds the limit, too? In this case,
> we could repeat the error until the top PG_CATCH(). Is this correct
> behaviour? Maybe to check in the exceeds_max_total_bkend_mem() for
> recursion and allow error handlers to slightly exceed this hard limit?
By the patch in attachment I try to show which sort of problems I'm
worrying about. In some PП_CATCH() sections we do CopyErrorData
(allocate some memory) before aborting the transaction. So, the
allocation error can move us out of this section before aborting. We
await for soft ERROR message but will face more hard consequences.

Andrey Lepikhov
Postgres Professional

Attachment Content-Type Size
reorder_operators.diff text/plain 2.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-10-03 12:15:48 Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
Previous Message Aleksander Alekseev 2023-10-03 11:28:18 Re: Modernize const handling with readline