DROP TABLE and autovacuum
От
ITAGAKI Takahiro
Тема
DROP TABLE and autovacuum
Дата
Msg-id
20070613141752.22EC.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Список
Дерево обсуждения
DROP TABLE and autovacuum ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: DROP TABLE and autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: DROP TABLE and autovacuum ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: DROP TABLE and autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: DROP TABLE and autovacuum Alvaro Herrera <alvherre@commandprompt.com>
Re: DROP TABLE and autovacuum ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
pgstat_drop_relation bugfix ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: DROP TABLE and autovacuum Tom Lane <tgl@sss.pgh.pa.us>
If we tries to drop the table on which autovacuum is running, we have to wait finish of the vacuum. However, the vacuuming effort goes to waste for the table being dropped or rewritten. Meanwhile, we've already had the autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands. Can we extend the feature to several TABLE commands? One simple solution is that every time a non-autovacuum backend tries to access a table with a lock equal or stronger than SHARE UPDATE EXCLUSIVE, the backend checks whether some autovacuum workers are vacuuming the table and send SIGINT to them. Is this worth doing? Or are there any dangerous situation in it? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления