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 по дате отправления: