Re: Parent/child context relation in pg_get_backend_memory_contexts() - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: Parent/child context relation in pg_get_backend_memory_contexts()
Date
Msg-id CAGPVpCSY4RvtfY7RfdLgE_GC2hjtHr_OqtYQm-eWAi=6UALKyQ@mail.gmail.com
Whole thread Raw
In response to Re: Parent/child context relation in pg_get_backend_memory_contexts()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Parent/child context relation in pg_get_backend_memory_contexts()
List pgsql-hackers
Hi,

Michael Paquier <michael@paquier.xyz>, 14 Şub 2024 Çar, 10:23 tarihinde şunu yazdı:
On Fri, Jan 19, 2024 at 05:41:45PM +0900, torikoshia wrote:
> We already have additional description below the table which explains each
> column of the system view. For example pg_locks:
> https://www.postgresql.org/docs/devel/view-pg-locks.html

I was reading the patch, and using int[] as a representation of the
path of context IDs up to the top-most parent looks a bit strange to
me, with the relationship between each parent -> child being
preserved, visibly, based on the order of the elements in this array
made of temporary IDs compiled on-the-fly during the function
execution.  Am I the only one finding that a bit strange?  Could it be
better to use a different data type for this path and perhaps switch
to the names of the contexts involved?

Do you find having the path column strange all together? Or only using temporary IDs to generate that column? The reason why I avoid using context names is because there can be multiple contexts with the same name. This makes it difficult to figure out which context, among those with that particular name, is actually included in the path. I couldn't find any other information that is unique to each context.

Thanks,
--
Melih Mutlu
Microsoft

pgsql-hackers by date:

Previous
From: Panda Developpeur
Date:
Subject: [PATCH] Modify pg_ctl to detect presence of geek user
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Modify pg_ctl to detect presence of geek user