The following bug has been logged online:

Bug reference: 2486
Logged by: Ronald
Email address: lobster2 (AT) xs4all (DOT) nl
PostgreSQL version: 8.1.4
Operating system: FreeBSD 6.0
Description: PANIC when CTRL-C on vacuum full analyze
Details:

Logging:

LOG: checkpoints are occurring too frequently (24 seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".
LOG: checkpoints are occurring too frequently (27 seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".
LOG: checkpoints are occurring too frequently (27 seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".
LOG: checkpoints are occurring too frequently (29 seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".
ERROR: canceling statement due to user request
PANIC: cannot abort transaction 2085, it was already committed
LOG: server process (PID 3628) was terminated by signal 6
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
FATAL: the database system is starting up
LOG: database system was interrupted at 2006-06-18 22:03:10 CEST
LOG: checkpoint record is at 1/F0011F14
LOG: redo record is at 1/F0010D58; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 2086; next OID: 16404
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 1/F0010D58
LOG: record with zero length at 1/F002E3AC
LOG: redo done at 1/F002E370
LOG: database system is ready
LOG: transaction ID wrap limit is 1073742643, limited by database "test"

BUG: The PANIC resulting from terminating the vacuum full verbose analyze on
a table. The vacuum was issued from a psql prompt.

The table being vacuumed has got 3,000,000 (million) records. I filled it
up, then deleted all entries with a DELETE <table>, then filled it up again.
When finished, I ran VACUUM FULL VERBOSE ANALYZE <table>. Unfortunately I
did not save the terminal output.

I tried to reproduce this PANIC but have not succeeded thus far :-(. The run
that went wrong had run for about two hours before I stopped it.

Postgress version: PostgreSQL 8.1.4 on i386-unknown-freebsd6.0, compiled by
GCC gcc (GCC) 3.4.4 [FreeBSD] 20050518

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"Ronald" <lobster2 (AT) xs4all (DOT) nl> writes:
I think we've seen this reported once before. You'd need to hit the
window where VACUUM FULL has committed its transaction but is still busy
cleaning indexes. Having moved a whole lot of rows would contribute to
making that window wider ...

I haven't looked into a fix but I imagine the best thing would be to
start a real second transaction for the cleanup phase.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match