"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: > Silvio Brandani <silvio.brandani@xxxxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
