Silvio Brandani <silvio(dot)brandani(at)tech(dot)sdb(dot)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 .
> But we encounter following problem:
> with kill command:
>
> 2010-11-03 14:25:27 CET [19324]: [4-1] FATAL: terminating
> connection due to administrator command
> 2010-11-03 14:25:27 CET [19324]: [5-1] STATEMENT: vacuum full
> analyze verbose tracking.as_history_status ;
> 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC: cannot abort
> transaction 75073917, it was already committed
>
> with pg_cancel_backend(pid) command:
>
> CPU 0.18s/0.26u sec elapsed 3.79 sec.
> ERROR: canceling statement due to user request
> PANIC: cannot abort transaction 75081452, it was already
> committed server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !> quit
> -> \q
>
> the server crash and we have a service unavailiability on our
> production system.
What version of PostgreSQL is this?
> 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.
Have you recovered your database yet? If so how? (Restart, PITR
backup, pg_dump output, etc.)
-Kevin