From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Pacheco <dap(at)joyent(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postmaster deadlock while logging after syslogger exited |
Date: | 2017-11-17 01:50:40 |
Message-ID: | 20171117015040.m36ovf5dqtg3star@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2017-11-06 15:35:03 -0500, Tom Lane wrote:
> David Pacheco <dap(at)joyent(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-17 02:09:56 | Re: postmaster deadlock while logging after syslogger exited |
Previous Message | David Pacheco | 2017-11-17 00:11:16 | Re: postmaster deadlock while logging after syslogger exited |