Re: [GENERAL] postmaster deadlock while logging after syslogger exited

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

In response to

Responses

Browse pgsql-general by date

  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