To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: pgsql-admin@postgresql.org,
 "Silvio Brandani" <silvio.brandani@tech.sdb.it>
Subject: Re: PANIC killing vacuum process 
In-reply-to: <4CD1476302000025000371FC@gw.wicourts.gov> 
References: <4CD1886C.5000503@tech.sdb.it>
	<4CD1476302000025000371FC@gw.wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Wed, 03 Nov 2010 11:28:35 -0500"
Date: Wed, 03 Nov 2010 12:41:41 -0400
Message-ID: <8288.1288802501@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Silvio Brandani <silvio.brandani@tech.sdb.it> wrote:
>> we have develop a script to execute the vacuum full on all tables
>> of our very big database , since it is a 24 x 7 available system
>> we have not a timeframe to exec the vacuum full.
>> so we try with this script running the vauum full table by table
>> and if the vacuum generate the waiting status for other
>> connections we kill the vacuum .
>> [ and get ]
>> 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC:  cannot abort
>> transaction 75073917, it was already committed

> What version of PostgreSQL is this?

Anything pre-9.0 might do that; it's one of the known problems with the
old VACUUM FULL implementation that made us decide to get rid of it.

However, versions that are less than about a year old do have a hack
that should avoid the PANIC for a query-cancel interrupt ... at the
cost of ignoring the cancel interrupt, so that's not all that helpful
a solution here.
 
>> Is it possible to softly kill a vacuum process without risk a
>> panic ?????
 
> Normally, yes.  VACUUM FULL is more prone to problems than a normal
> vacuum, especially if you are using an old version.  There are very
> few circumstances where VACUUM FULL is the right thing to use.

Indeed.  If you think you need to use VACUUM FULL on a routine basis,
rethink that.

			regards, tom lane