From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> |
Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parent/child context relation in pg_get_backend_memory_contexts() |
Date: | 2024-04-03 23:34:04 |
Message-ID: | Zg3nbJPBTqDa4yGG@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 03, 2024 at 04:20:39PM +0300, Melih Mutlu wrote:
> Michael Paquier <michael(at)paquier(dot)xyz>, 14 Şub 2024 Çar, 10:23 tarihinde
> şunu yazdı:
>> 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.
I've been re-reading the patch again to remember what this is about,
and I'm OK with having this "path" column in the catalog. However,
I'm somewhat confused by the choice of having a temporary number that
shows up in the catalog representation, because this may not be
constant across multiple calls so this still requires a follow-up
temporary ID <-> name mapping in any SQL querying this catalog. A
second thing is that array does not show the hierarchy of the path;
the patch relies on the order of the elements in the output array
instead.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-04-03 23:50:52 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Previous Message | Michael Paquier | 2024-04-03 23:24:25 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |