A few WEEKS ago, the autovacuum on my instance of pg 7.4 unilaterally
decided to VACUUM a table which has not been updated in over a year and
is more than one terabyte on the disk. Because of the very high
transaction load on this database, this VACUUM has been ruining
performance for almost a month. Unfortunately is seems invulnerable to
killing by signals:
# ps ax | grep VACUUM
15308 ? D 588:00 postgres: postgres skunk [local] VACUUM
# kill -HUP 15308
# ps ax | grep VACUUM
15308 ? D 588:00 postgres: postgres skunk [local] VACUUM
# kill -INT 15308
# ps ax | grep VACUUM
15308 ? D 588:00 postgres: postgres skunk [local] VACUUM
# kill -PIPE 15308
# ps ax | grep VACUUM
15308 ? D 588:00 postgres: postgres skunk [local] VACUUM
o/~ But the cat came back, the very next day ...
I assume that if I kill this with SIGKILL, that will bring down every
other postgres process, so that should be avoided. But surely there is
a way to interrupt this. If I had some reason to shut down the
instance, I'd be screwed, it seems.
-jwb
---------------------------(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
