Re: Parent/child context relation in pg_get_backend_memory_contexts()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-07-15 17:56:05
Message-ID: CA+TgmoamTJnM5XGVj_xCM-Sd-285a9KAwWwjwYhuUDED4r5f4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 12, 2024 at 6:33 PM Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)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 most users would be interested in will likely be unique on their levels and with their name. So we might not be concerned with the contexts, like those two from the above result, and chose using names instead of transient IDs. But I think that 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-07-15 18:12:45 Re: long-standing data loss bug in initial sync of logical replication
Previous Message Robert Haas 2024-07-15 17:44:58 Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions