Re: strange buildfarm failures
От | Alvaro Herrera |
---|---|
Тема | Re: strange buildfarm failures |
Дата | |
Msg-id | 20070502131831.GD4585@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: strange buildfarm failures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: strange buildfarm failures
|
Список | pgsql-hackers |
Tom Lane wrote: > I wrote: > > Hmm ... I was about to say that the postmaster never sets > > PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW > > could do it? Does the postmaster ever execute PG_TRY? > > Doh, I bet that's it, and it's not the postmaster that's at issue > but PG_TRY blocks executed during subprocess startup. Inheritance > of a PG_exception_stack setting from the postmaster could only happen if > the postmaster were to fork() within a PG_TRY block, which I think we > can safely say it doesn't. But suppose we get an elog(ERROR) inside > a PG_TRY block when there is no outermost longjmp catcher. elog.c > will think it should longjmp, and that will eventually lead to > executing > > #define PG_RE_THROW() \ > siglongjmp(*PG_exception_stack, 1) > > with PG_exception_stack = NULL; which seems entirely likely to cause > a stack smash of gruesome dimensions. What's more, nothing would have > been printed to the postmaster log beforehand, agreeing with observation. I agree that that would be a bug and we should fix it, but I don't think it explains the problem we're seeing because there is no PG_TRY block in the autovac startup code that I can see :-( -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: