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.
