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

From Robert Haas
Subject Re: Parent/child context relation in pg_get_backend_memory_contexts()
Date
Msg-id CA+TgmoamTJnM5XGVj_xCM-Sd-285a9KAwWwjwYhuUDED4r5f4A@mail.gmail.com
Whole thread Raw
In response to Re: Parent/child context relation in pg_get_backend_memory_contexts()  (Melih Mutlu <m.melihmutlu@gmail.com>)
List pgsql-hackers
On Fri, Jul 12, 2024 at 6:33 PM Melih Mutlu <m.melihmutlu@gmail.com> wrote:
> I just ran the below  to see if we have any context with the same level and name.
>
> postgres=# select level, name, count(*) from pg_backend_memory_contexts group by level, name having count(*)>1;
>  level |    name     | count
> -------+-------------+-------
>      3 | index info  |    90
>      5 | ExprContext |     5
>
> Seems like it's a possible case. But those contexts might not be the most interesting ones. I guess the contexts that
mostusers would be interested in will likely be unique on their levels and with their name. So we might not be
concernedwith the contexts, like those two from the above result, and chose using names instead of transient IDs. But I
thinkthat we can't guarantee name-based path column would be completely reliable in all cases. 

Maybe we should just fix it so that doesn't happen. I think it's only
an issue if the whole path is the same, and I'm not sure whether
that's the case here. But notice that we have this:

        const char *name;                       /* context name (just
for debugging) */
        const char *ident;                      /* context ID if any
(just for debugging) */

I think this arrangement dates to
442accc3fe0cd556de40d9d6c776449e82254763, and the discussion thread
begins like this:

"It does look like a 182KiB has been spent for some SQL, however
there's no clear way to tell which SQL is to blame."

So the point of that commit was to find better ways of distinguishing
between similar contexts. It sounds like perhaps we're not all the way
there yet, but if we agree on the goal, maybe we can figure out how to
reach it.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Next
From: vignesh C
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication