Re: strange buildfarm failures

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: strange buildfarm failures
Дата
Msg-id 20070429162552.GH18593@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: strange buildfarm failures  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: strange buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> 
> > well - i now have a core file but it does not seem to be much worth
> > except to prove that autovacuum seems to be the culprit:
> > 
> > Core was generated by `postgres: autovacuum worker process
> >                              '.
> > Program terminated with signal 6, Aborted.
> > 
> > [...]
> > 
> > #0  0x00000ed9 in ?? ()
> > warning: GDB can't find the start of the function at 0xed9.
> 
> Interesting.  Notice how it doesn't have the database name in the ps
> display.  This means it must have crashed between the initial
> init_ps_display and the set_ps_display call just before starting to
> vacuum.  So the bug is probably in the startup code; probably the code
> dealing with the PGPROC which is the newest and weirder stuff.

Oh, another thing that I think may be happening is that the stack is
restored in longjmp, so it is trying to report an error elsewhere but
it crashes because something got overwritten or something; i.e. a
bug in the error recovery code.  I don't know how feasible this is or
even if it makes sense (would longjmp() restore the ps display?), but we
had similar, very hard to debug errors in Mammoth Replicator, which is
why I'm mentioning it in case it rings a bell.

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
"The only difference is that Saddam would kill you on private, where the
Americans will kill you in public" (Mohammad Saleh, 39, a building contractor)


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: strange buildfarm failures
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Reducing stats collection overhead