ITAGAKI Takahiro wrote: > 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?
Well, one problem with this is that currently SIGINT cancels the whole autovacuum worker, not just the table currently being processed. I think this can be fixed easily by improving the signal handling. Aside from that, I don't see any problem in handling DROP TABLE like you suggest. But I don't feel comfortable with doing it with just any strong locker, because that would easily starve tables from being vacuumed at all. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
