8.3.1 autovacuum stopped doing anything months ago
От | Jeffrey Baker |
---|---|
Тема | 8.3.1 autovacuum stopped doing anything months ago |
Дата | |
Msg-id | fd145f7d0809182123p2103216oe8b8c96b4ada31d3@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: 8.3.1 autovacuum stopped doing anything months ago
Re: 8.3.1 autovacuum stopped doing anything months ago |
Список | pgsql-hackers |
<div dir="ltr">I have an 8.3.1 instance on Linux and since June 29th the autovacuum process has claimed to be working onthe same three tables. That's OK, I am a very patient man, and these are very large tables. Today I started to get transactionwraparound warnings, so I go and check it out. Turns out the autovacuum processes are all just doing nothing. When I strace them, they are all three blocked on syscalls.<br /><br />So I restart the database and run a vacuum. Of course, once the wraparound warning is reached, there's no way to disable the autovac, so now my vacuum maintenancejob is competing with three invulnerable autovacuum processes. I am thinking of sending them SIGSTOP.<br /><br/>Anyway, I have some issues. One, of course, is that the autovacuum should not have been deadlocked or otherwise stalledlike that. Perhaps it needs a watchdog of some kind. Has anyone else experienced an issue like that in 8.3.1? Theonly thing I can see in the release notes that indicates this problem may have been fixed is the following:<br /><br />"Repairtwo places where SIGTERM exit of a backend could leave corrupted state in shared memory (Tom)" <br /><br />HoweverI don't know who or what would have sent SIGTERM to the autovacuum children.<br /><br />Secondly, there really doesneed to be an autovacuum=off,really,thanks so that my maintenance can proceed without competition for i/o resources. Is there any way to make that happen? Is my SIGSTOP idea dangerous?<br /><br />-jwb<br /></div>
В списке pgsql-hackers по дате отправления: