Message-ID: <36f05c1e1c8b26ce92855f7fbea3e56d5ae15899.camel@crunchydata.com>
Subject: Re: Add the ability to limit the amount of memory that can be
 allocated to backends.
From: Reid Thompson <reid.thompson@crunchydata.com>
Reply-To: reid.thompson@crunchydata.com
To: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Cc: reid.thompson@crunchydata.com
In-Reply-To: <3b9b90c6-f4ae-a7df-6519-847ea9d5fe1e@amazon.com>
References: <bd57d9a4c219cc1392665fd5fba61dde8027b3da.camel@crunchydata.com>
	 <3b9b90c6-f4ae-a7df-6519-847ea9d5fe1e@amazon.com>
Organization: Crunchy Data
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Sep 2022 20:25:06 -0400
MIME-Version: 1.0
User-Agent: Evolution 3.45.1 Compiled: 2022-06-07 10:22:05
Archived-At: 
 <https://www.postgresql.org/message-id/36f05c1e1c8b26ce92855f7fbea3e56d5ae15899.camel%40crunchydata.com>
Precedence: bulk

On Fri, 2022-09-02 at 09:30 +0200, Drouvot, Bertrand wrote:
> Hi,
>=20
> I'm not sure we are choosing the right victims here (aka the ones
> that are doing the request that will push the total over the limit).
>
> Imagine an extreme case where a single backend consumes say 99% of
> the limit, shouldn't it be the one to be "punished"? (and somehow forced
> to give the memory back).
>=20
> The problem that i see with the current approach is that a "bad"
> backend could impact all the others and continue to do so.
>=20
> what about punishing say the highest consumer , what do you think?
> (just speaking about the general idea here, not about the implementation)

Initially, we believe that punishing the detector is reasonable if we
can help administrators avoid the OOM killer/resource starvation.  But
we can and should expand on this idea.

Another thought is, rather than just failing the query/transaction we
have the affected backend do a clean exit, freeing all it's resources.


--=20
Reid Thompson
Senior Software Engineer
Crunchy Data, Inc.

reid.thompson@crunchydata.com
www.crunchydata.com