Hi, Jeffrey, Jeffrey W. Baker wrote: > 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. Hmm, maybe this is the Transaction ID wraparound emerging, and VACUUM is freezing the rows. Did you VACUUM FREEZE the table after the last modifications? > # kill -HUP 15308 > # kill -INT 15308 > # kill -PIPE 15308 Did you try kill -TERM? This always cleanly ended VACUUMing backends on our machines within seconds. > 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. Yes, SIGKILL will make the postmaster shut down all running backend instances, the same as SIGSEGV and possibly a few others. The reason is that the postmaster assumes some internal data structure corruption in the shared memory pages is possible on an "unclean" backend abort, and thus quits immediately to minimize the possibility of those corruptions to propagate to the disks. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
