Re: [GENERAL] postmaster deadlock while logging after sysloggerexited
От | Andres Freund |
---|---|
Тема | Re: [GENERAL] postmaster deadlock while logging after sysloggerexited |
Дата | |
Msg-id | 20171117015040.m36ovf5dqtg3star@alap3.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
Re: [GENERAL] postmaster deadlock while logging after syslogger exited |
Список | pgsql-general |
On 2017-11-06 15:35:03 -0500, Tom Lane wrote: > David Pacheco <dap@joyent.com> writes: > > I ran into what appears to be a deadlock in the logging subsystem. It > > looks like what happened was that the syslogger process exited because it > > ran out of memory. But before the postmaster got a chance to handle the > > SIGCLD to restart it, it handled a SIGUSR1 to start an autovacuum worker. > > That also failed, and the postmaster went to log a message about it, but > > it's blocked on the pipe that's normally connected to the syslogger, > > presumably because the pipe is full because the syslogger is gone and > > hasn't read from it. > > Ugh. I'm somewhat inclined to say that one has to live with this if the system is so resource constrainted that processes barely using memory get killed. We could work around a situation like that if we made postmaster use a *different* pipe as stderr than the one we're handing to normal backends. If postmaster created a new pipe and closed the read end whenever forking a syslogger, we should get EPIPEs when writing after syslogger died and could fall back to proper stderr or such. Greetings, Andres Freund -- 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 по дате отправления: