Re: autovacuum process (PID ...) was terminated by signal 11
От | Brian Hirt |
---|---|
Тема | Re: autovacuum process (PID ...) was terminated by signal 11 |
Дата | |
Msg-id | AC3E7F38-D3F6-44D0-8667-237BF79D70DF@mobygames.com обсуждение исходный текст |
Ответ на | Re: autovacuum process (PID ...) was terminated by signal 11 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: autovacuum process (PID ...) was terminated by signal 11
Re: autovacuum process (PID ...) was terminated by signal 11 |
Список | pgsql-bugs |
Cool, I was just writing to let you know I created an easily reproducible test case too, but I guess you don't need that now. Let me know if there is anything else I can do to help. Also, if a patch is produced, I'd love to get a copy of it. We just upgraded our production servers to 8.1.1 this morning (this issue never came up during testing) and I'l like to get this in there because it's likely to happen again. --brian On Jan 4, 2006, at 11:31 AM, Tom Lane wrote: > Brian Hirt <bhirt@mobygames.com> writes: >> I can analyze that table without problems. I don't know if it's the >> same table every time. I'm trying to set up a development >> environment where i can test this stuff better without messing up our >> production systems. The table does have an expresional index. > > I've managed to reproduce this: the triggering condition is that a > single autovac iteration has to VACUUM one table and then ANALYZE > (no vac) another table that has an expressional index with a plpgsql > function. It looks like we missed a path of control where > ActiveSnapshot has to be re-set-up, but I'm not clear where. > > regards, tom lane -------------------------------------------- MobyGames http://www.mobygames.com The world's largest and most comprehensive gaming database project
В списке pgsql-bugs по дате отправления: