On November 16, 2017 7:06:23 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.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
loggingin a workload with many large query strings might do it. So making it less likely to be killed might make the
problemworse...
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general