Re: postmaster deadlock while logging after syslogger exited

On November 16, 2017 7:06:23 PM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-11-16 21:39:49 -0500, Tom Lane wrote:
>>> What might be worth thinking about is allowing the syslogger process
>to
>>> inherit the postmaster's OOM-kill-proofness setting, instead of
>dropping
>>> down to the same vulnerability as the postmaster's other child
>processes.
>
>> Hm. I'm a bit scared about that - it doesn't seem that inconceivable
>> that various backends log humongous multi-line messages, leading to
>> syslogger *actually* taking up a fair amount of memory. Note that
>we're
>> using plain stringinfos that ereport(ERROR) out of memory situations,
>> rather than failing more gracefully.
>
>True, but there's no hard limits on the postmaster's memory consumption
>either ...

Is there a credible scenario where it'd allocate many gigabytes of memory?

> and if the syslogger does get killed on such a basis, we
>have at the least lost a bunch of log output. On the whole I think we'd be
>better off trying to prevent OOM kills on the syslogger. (That doesn't
>preclude other mitigation measures.)

It doesn't seem impossible to get into a situation where syslogger is the source of the OOM. Just enabling a lot of logging in a workload with many large query strings might do it. So making it less likely to be killed might make the problem worse...

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.