From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Backend memory dump analysis |
Date: | 2018-03-27 17:29:14 |
Message-ID: | 23168.1522171754@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> My only gripe is the pattern where the identifier needs to be
> re-installed when resetting the context. I don't think we need to hold
> push for that reason alone, but I bet we'll be revisiting that.
Yeah, that's slightly annoying; if I'd found more than one case of that,
I'd want a better answer. But it seems like contexts that are long-lived
enough to warrant labeling typically don't get reset during their
lifespans, so it shouldn't be a huge problem.
I considered having MemoryContextReset either Assert that context->ident
is NULL, or just forcibly reset it to NULL, thus preventing a dangling
pointer if someone gets this wrong. But that would lock out a perfectly
valid coding pattern where the identifier is in the parent context, so
I'm not convinced it's a good idea.
> I suppose this infrastructure can be used to implement the idea in
> https://www.postgresql.org/message-id/CAMsr+YHii-BCC7ddpbb8fpCgzt0wMRt5GYZ0W_kD_Ft8rwWPiQ@mail.gmail.com
> in some more acceptable manner. I'm not proposing it for now, just
> parking the idea for a future patch.
Ah, I thought I remembered the callback idea from some previous
discussion, but I'd not located this one. I think I've got a nicer
API for the per-context-type stats functions than what Craig
proposes there, but we could imagine doing this API or something
close to it for MemoryContextStatsInternal. Or, as I mentioned
before, an external caller could just implement the scan over the
context tree for itself, and format the data however it wants.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-03-27 17:29:48 | Re: [HACKERS] why not parallel seq scan for slow functions |
Previous Message | Robert Haas | 2018-03-27 17:18:36 | Re: Parallel safety of binary_upgrade_create_empty_extension |