Re: Add the ability to limit the amount of memory that can be allocated to backends. - Mailing list pgsql-hackers

From David Rowley
Subject Re: Add the ability to limit the amount of memory that can be allocated to backends.
Date
Msg-id CAApHDvqQufvtL1XV6vMDdZ5T=0jQSzc13txfy-EvXy-RR4xF3g@mail.gmail.com
Whole thread Raw
In response to Re: Add the ability to limit the amount of memory that can be allocated to backends.  (James Hunter <james.hunter.pg@gmail.com>)
Responses Re: Add the ability to limit the amount of memory that can be allocated to backends.
List pgsql-hackers
On Tue, 31 Dec 2024 at 10:11, James Hunter <james.hunter.pg@gmail.com> wrote:
> Does PostgreSQL currently rescan Hash Joins when they are "no longer
> needed," to free work_mem early? If so, then I would try to reuse this
> existing logic to decide which nodes need work_mem concurrently.
>
> If not, then all nodes that use work_mem actually use it
> "concurrently," because we don't free that work_mem until we call
> ExecutorEnd().

The problem with that statement is that Hash Join isn't the only node
type that uses work_mem. Plenty of other node types do.  Have a look
at MultiExecBitmapOr(). You can see logic there that does tbm_free()
after the tbm_union() call. Going by that, it seems there is at least
one place where we might free some work_mem memory before allocating
another lot.

David



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: RFC: Allow EXPLAIN to Output Page Fault Information