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
