Re: more on out-of-memory

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: more on out-of-memory
Дата
Msg-id 17369.1239071786@sss.pgh.pa.us
обсуждение исходный текст
Ответ на more on out-of-memory  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> So, the reason I started the thread about postmaster dying on OOM is
> that somebody asked me on IM what could have caused a backend to die
> with this backtrace:

[ of course you realize this is a backend, not the postmaster ]

> His question was: is it possible that we're handing a NULL pointer to a
> %s on fprintf?  The involved code looks like this:
> ...
> And since this is being called from AllocSetAlloc, which is always
> handed a complete memory context (and not something that has only been
> partially set), I think the answer is that it's not possible, and that
> the bug must be on libc which is perhaps not handling out-of-memory very
> cleanly in its fprintf implementation.

Another theory is that the name pointer got clobbered by some sort of
memory-stomping bug.  (We don't know from the available evidence that
it was NULL --- it could have been any garbage value that pointed
outside backend memory.)  However, given that the context clearly
indicates being out-of-memory overall, your theory seems a bit more
probable.

The really odd thing is that the stack trace is so short; it seems
to have failed *very* early in query parsing, which is hard to credit
unless this person is in the habit of sending megabytes-long queries.
I guess if the system as a whole were under really severe memory
pressure, a backend could hit OOM without having eaten much itself.

What platform is this, and which PG version?
        regards, tom lane


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: unchecked out of memory in postmaster.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: unchecked out of memory in postmaster.c