Re: [GENERAL] postmaster deadlock while logging after syslogger exited
От | Andres Freund |
---|---|
Тема | Re: [GENERAL] postmaster deadlock while logging after syslogger exited |
Дата | |
Msg-id | 5B347B42-1A82-448A-9814-CAAB3BA189E8@anarazel.de обсуждение исходный текст |
Ответ на | Re: [GENERAL] postmaster deadlock while logging after syslogger exited (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] postmaster deadlock while logging after syslogger exited
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: