MIME-Version: 1.0
References: <ZzV-8qOOBtPdP4Tq@paquier.xyz>
 <7d4db5cf-8d72-4ee1-8f2e-f88ef9615f27@vondra.me>
 <CAH2L28uvYHX1CfmbcB9JPzR6+MzJ+kb9ob+NvFy3wUHM8HUkGA@mail.gmail.com>
 <637b3ae3-b9eb-4d83-a942-5f7483911ea4@vondra.me>
 <CAH2L28spk4c54k5pTSWRqu5LJmetQwTXtr=-F7Bnioxd425hqQ@mail.gmail.com>
 <29ced66e28ec696d1ac29747bd901df2@oss.nttdata.com>
 <CAH2L28vEiz+Qxw=Y5Dze8_TxDW1kAyh_3R-BKUGvOH6r02W6cg@mail.gmail.com>
 <5a899047-65fc-47c5-9c35-1035f44956c6@vondra.me>
 <CAH2L28vR622wV44XenbhWc7ETpNtjS_oeTha7OxMx35LjWPPqQ@mail.gmail.com>
 <70146bd0-da0f-48ee-bece-1e35536189e0@oss.nttdata.com>
 <CAH2L28u7=fcgnY8bpM87moiJxt++wqWZXh2HxFabYjiHSg76Cg@mail.gmail.com>
 <2eb8fd76-89f0-42e8-bc79-152d50c63016@vondra.me>
 <CAH2L28vYvC5DP+YccBE7VnC-khn3k_vd=MGxn8BFEpLc40ncHw@mail.gmail.com>
 <81607c8c04a21b5cac87b21e46566074@oss.nttdata.com>
 <CAH2L28sNHmj+aCJ=XkNb0an-XAs3eOUcU4orx2G9yviRL560fg@mail.gmail.com>
 <CAH2L28sMnNy9DvzAAoiE8qQs0MRX9ALhaYAf2f-aLivL47Ryhw@mail.gmail.com>
 <4c2b5401-41ad-43b9-9215-c7b2d901f8ed@vondra.me>
 <CAH2L28uayhv+AxgPLThexJ21NA8j7XFiYqu6rgsZSSNosvPjvg@mail.gmail.com>
 <84996B31-C278-4373-8F56-C5A38A4530BA@yesql.se>
 <CAH2L28s8Etbz2XM0xiH=RyRHAnEAxMD2AVpvcHyhHEHTbf-Uqg@mail.gmail.com>
 <CAH2L28vULzqoit+YCKR5UhdT+AR+b1Qcs6Hgpz6nQz6NBT2jug@mail.gmail.com>
In-Reply-To: 
 <CAH2L28vULzqoit+YCKR5UhdT+AR+b1Qcs6Hgpz6nQz6NBT2jug@mail.gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sat, 15 Mar 2025 10:40:39 +0200
Message-ID: 
 <CAPpHfdu1pxssAYAUkpQJBvgENCfVZetFL3v1txrWDUiKV80hJw@mail.gmail.com>
Subject: Re: Enhancing Memory Context Statistics Reporting
To: Rahila Syed <rahilasyed90@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Tomas Vondra <tomas@vondra.me>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdu1pxssAYAUkpQJBvgENCfVZetFL3v1txrWDUiKV80hJw%40mail.gmail.com>
Precedence: bulk

Hi, Rahila!

On Thu, Mar 13, 2025 at 3:57=E2=80=AFPM Rahila Syed <rahilasyed90@gmail.com=
> wrote:
>
> Please find attached updated and rebased patches. It has the following ch=
anges
>
> 1. To prevent memory leaks, ensure that the latest statistics published b=
y a process
> are freed before it exits. This can be achieved by calling dsa_free in th=
e
> before_shmem_exit callback.
> 2. Add a level column to maintain consistency with the output of
> pg_backend_memory_contexts.

Thank you for your work on this subject.

v17-0001-Preparatory-changes-for-reporting-memory-context-sta.patch

It looks like we're increasing *num_contexts twice per child memory
context.  First, it gets increased with a recursive
MemoryContextStatsInternal() call, then by adding an ichild.  I might
be wrong, but I think these calculations at least deserve more
comments.

v17-0002-Function-to-report-memory-context-statistics.patch

+   if (procNumber =3D=3D MyProcNumber)
+   {
+       ereport(WARNING,
+               errmsg("cannot return statistics for local backend"),
+               errhint("Use pg_backend_memory_contexts view instead."));
+       PG_RETURN_NULL();
+   }

Is it worth it to keep this restriction?  Can we fetch info about
local memory context for the sake of generality?

I know there have been discussions in the thread before, but the
mechanism of publishing memory context stats via DSA looks quite
complicated.  Also, the user probably intends to inspect memory
contexts when there is not a huge amount of free memory.  So, failure
is probable on DSA allocation.  Could we do simpler?  For instance,
allocate some amount of static shared memory and use it as a message
queue between processes.  As a heavy load is not supposed to be here,
I think one queue would be enough.

------
Regards,
Alexander Korotkov
Supabase