From: | David Pacheco <dap(at)joyent(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] postmaster deadlock while logging after syslogger exited |
Date: | 2017-12-04 21:57:52 |
Message-ID: | CACukRjNe6SWF=__9O4oWOve6QscjYZwmK_ec0u57fEira9pGtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Dec 4, 2017 at 12:23 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2017-11-20 11:12:08 -0800, David Pacheco wrote:
> > $ ps -opid,rss,vsz,args -p 37627
> > PID RSS VSZ COMMAND
> > 37627 2980 14968 /opt/postgresql/9.2.4/bin/postgres -D /manatee/pg/data
> >
> > I'm not sure what we can infer from that, as this is a different system,
> > and the workload that generates the very large query strings only runs
> > occasionally. Those strings are also not logged unless something's gone
> > wrong.
>
> FWIW, I'd like to see a report of this around the time the issue
> occurred before doing anything further here.
>
This failure begins when this process exits, so the best you could get is
memory in use immediately before it exited. I obviously can't get that now
for the one instance I saw weeks ago, but maybe PostgreSQL could log
information about current memory usage when it's about to exit because of
ENOMEM? That way if anybody hits a similar condition in the future, the
data will be available to answer your question.
That said, I think the deadlock itself is pretty well explained by the data
we have already.
-- Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-12-04 22:12:15 | Re: [GENERAL] postmaster deadlock while logging after syslogger exited |
Previous Message | Alvaro Herrera | 2017-12-04 21:12:50 | Re: WAL reducing size |