Re: Using ProcSignal to get memory context stats from a running backend

On 13 December 2017 at 12:10, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Dec 11, 2017 at 10:07 PM, Craig Ringer <craig(at)2ndquadrant(dot)com>
> wrote:
> > On 12 December 2017 at 12:43, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> On 2017-12-12 11:57:41 +0800, Craig Ringer wrote:
> >> But that'd have
> >> the disadvanatage that it possibly would take a while till the
> >> MemoryContextStats() is executed. Not sure if that's still good enough
> >> for you?
> >
> > Definitely. Sure, it won't be perfect, but it'd be a big improvement on
> what
> > we have.
>
> If this would be fine enough, why not giving a shot then? Having to
> use gdb now on production systems is something sometimes hard to
> justify to customers. There are also the Windows problems...
>
> >> Another question is whether printing to stderr, bypassing proper
> >> logging!, is good enough for something like this.
> >
> > I think the reason it prints to stderr now is that it's intended to run
> in
> > OOM situations.
>
> Yep. I am on board with Tom here that this property should not be thrown
> away.
>
>

OK, so I think I'll do pretty much what I outlined above, using stringinfo
for the !OOM case and fprintf for the OOM case, via callback, roughly as
outlined upthread. I won't bother with elog, it's easy enough if someone
cares.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services