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

On 22 December 2017 at 13:05, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 21 December 2017 at 15:55, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
>> On 21 December 2017 at 15:24, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>
>>> Hi,
>>>
>>> On 2017-12-21 15:13:13 +0800, Craig Ringer wrote:
>>> > There tons of callers to enlargeStringInfo, so a 'noerror' parameter
>>> would
>>> > be viable.
>>>
>>> Not sure what you mean with that sentence?
>>>
>>
>> Mangled in editing and sent prematurely, disregard.
>>
>> There are NOT tons of callers to enlargeStringInfo, so adding a
>> parameter that allowed it to return a failure result rather than ERROR on
>> OOM seems to be a reasonable option. But it relies on repalloc(), which
>> will ERROR on OOM. AFAICS we don't have "no error" variants of the memory
>> allocation routines and I'm not eager to add them. Especially since we
>> can't trust that we're not on misconfigured Linux where the OOM killer will
>> go wild instead of giving us a nice NULL result.
>>
>> So I guess that means we should probably just do individual elog(...)s
>> and live with the ugliness of scraping the resulting mess out of the logs.
>> After all, a log destination that could possibly copy and modify the string
>> being logged a couple of times it's not a good idea to try to drop the
>> whole thing into the logs in one blob. And we can't trust things like
>> syslog with large messages.
>>
>> I'll follow up with a revised patch that uses individual elog()s soon.
>>
>
> I intend to add an elog_internal_raw
>

Er, I mean

errmsg_internal_raw(const char * errmsg)

i.e. like errmsg_internal, but with no varargs or format string, to be used
when we want to prepare a simple preformatted log entry.

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