On 21 December 2017 at 15:55, Craig Ringer <cr...@2ndquadrant.com> wrote:
> On 21 December 2017 at 15:24, Andres Freund <and...@anarazel.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 for this, which takes a pre-formatted
string and bypasses EVALUATE_MESSAGE. In this case, one written to a static
buffer by vsnprintf.
That bypasses two rounds of allocations by elog - expand_fmt_string for %m
substitution, and the appendStringInfoVA for formatting. And it's a whole
lot cleaner than
char buffer[2048];
...
vsnprintf(buffer, sizeof(buffer), ...)
...
elog(LOG, "%s", buffer);
It still imposes a single-line length limit, but no worse than write_stderr
already does on win32. If that's not OK, preformatting each line a
StringInfo before dumping straight to elog works too.
Complaints or seem OK?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
