Cancel autovacuum conflicting with DROP TABLE
От | ITAGAKI Takahiro |
---|---|
Тема | Cancel autovacuum conflicting with DROP TABLE |
Дата | |
Msg-id | 20070620111526.6956.ITAGAKI.TAKAHIRO@oss.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: Cancel autovacuum conflicting with DROP TABLE
|
Список | pgsql-patches |
Here is a patch that cancels autovacuum workers conflicting with DROP TABLE, TRUNCATE and CLUSTER. It was discussed here: http://archives.postgresql.org/pgsql-hackers/2007-06/msg00556.php Before backends drop a table, they search autovacuum workers that are running on the table. If found, they send SIGINT signal to the autovacuum to avoid waiting for the worthless vacuum. When an autovacuum worker receives SIGINT, it skips only the vacuuming table and continues the remaining jobs. Now SIGINT and SIGTERM have different meanings and their logs are changed. SIGINT -- Cancel the current job. DEBUG: autovacuum on relation <schema>.<table> is canceled SIGTERM -- Cancel all jobs. FATAL: terminating autovacuum due to administrator command We can see the second SIGTERM log on shutdown and DROP DATABASE. In such case, we send SIGTERM to autovacuums instead of SIGINT. I'd like to bring down the error level to WARNING or less actually, but I have no idea to do it because canceling queries and error levels are tightly coupled in the present implementation. Instead, I added the special FATAL message for autovacuum workers so that we can distinguish the lines are ignorable. Comments welcome. --- ITAGAKI Takahiro NTT Open Source Software Center
Вложения
В списке pgsql-patches по дате отправления: