On 13 December 2017 at 12:10, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Mon, Dec 11, 2017 at 10:07 PM, Craig Ringer <cr...@2ndquadrant.com> > wrote: > > On 12 December 2017 at 12:43, Andres Freund <and...@anarazel.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
