Re: [GENERAL] postmaster deadlock while logging after sysloggerexited

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [GENERAL] postmaster deadlock while logging after sysloggerexited
Дата
Msg-id 20171204221215.gj4ojkykmrglo5wl@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [GENERAL] postmaster deadlock while logging after syslogger exited  (David Pacheco <dap@joyent.com>)
Ответы Re: [GENERAL] postmaster deadlock while logging after syslogger exited  (David Pacheco <dap@joyent.com>)
Список pgsql-general
On 2017-12-04 13:57:52 -0800, David Pacheco wrote:
> On Mon, Dec 4, 2017 at 12:23 PM, Andres Freund <andres@anarazel.de> wrote:
> > 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?

It already does so.

What I was wondering about was the memory usage some time before it
dies. In particular while the workload with the long query strings is
running. ps output would be good, gdb'ing into the process and issuing
MemoryContextStats(TopMemoryContext) would be better.

> 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.

Well, it doesn't really explain the root cause, and thus the extent of
the fixes required. If the root cause is the amount of memory used by
syslogger, we can remove the deadlock, but the experience is still going
to be bad. Obviously better, but still bad.

Greetings,

Andres Freund


В списке pgsql-general по дате отправления:

Предыдущее
От: David Pacheco
Дата:
Сообщение: Re: [GENERAL] postmaster deadlock while logging after syslogger exited
Следующее
От: chris kim
Дата:
Сообщение: transaction wrap around