Re: Backend memory dump analysis - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Backend memory dump analysis
Date
Msg-id 21283.1522102329@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backend memory dump analysis  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Responses Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes:
> It takes just a single pass to compute "total" (and it takes no memory), so
> it would be much better if "TopMemoryContext: ..." was replaced with
> "Total memory used by all contexts is XXX bytes"
> Current TopMemoryContext row is extremely misleading.

This may or may not be a good thing to do, but in any case it's well
outside the scope of this patch, whose ambition is only to get additional
identification info attached to contexts for which that's useful.
Moreover, seeing how late we are in the v11 cycle, it's hard to justify
doing more; that smells like a new feature and the time for that is past
for this year.  The only reason I'm considering this patch now at all
is that it rethinks some API changes we made earlier in v11, and it'd be
nice to avoid an additional round of churn there in v12.

> PS. SQL text might involve sensitive information (e.g. logins, passwords,
> personal IDs), so there might be security issues with printing SQL by
> default.

Indeed, that's something that extensions would need to think about.
I do not believe it's an issue for MemoryContextStats though; the
postmaster log can already contain sensitive data.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel Aggregates for string_agg and array_agg