Re: autovacuum crash due to null pointer
От | Alvaro Herrera |
---|---|
Тема | Re: autovacuum crash due to null pointer |
Дата | |
Msg-id | 20080717154827.GC3934@alvh.no-ip.org обсуждение исходный текст |
Ответ на | autovacuum crash due to null pointer (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: autovacuum crash due to null pointer
Re: autovacuum crash due to null pointer |
Список | pgsql-hackers |
Tom Lane wrote: > There's a fairly interesting crash here: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguar&dt=2008-07-16%2003:00:02 > The buildfarm was nice enough to provide a stack trace at the bottom of > the page, which shows clearly that autovac tried to pfree a null > pointer. > > What I think happened was that the table that was selected to be > autovacuumed got dropped during the setup steps, leading get_rel_name() > to return NULL at line 2167. vacuum() itself would have fallen out > silently ... however, had it errored out, the attempts at error > reporting in the PG_CATCH block would have crashed. I'm having a hard time reproducing this problem; I added a pg_usleep() just before get_rel_name to have the chance to drop the table, but strangely enough it doesn't return NULL. It seems that the cache entry is not getting invalidated. Maybe there's something else that's needed to reproduce the crash. Anyway, I propose this patch in HEAD to close this hole. For 8.3 I'm thinking in just rearranging the get_*_name calls and adding the goto. Thoughts? I think there's another hole here: what happens if the table exists when get_rel_name is called, but the schema is dropped between that point and calling get_namespace_name? It is pretty unlikely but can it be discarded completely? What should we do in that case? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: