On November 16, 2017 7:06:23 PM PST, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >Andres Freund <andres@xxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
