vacuum can't find clog

This is on a linux box, postgres 8.0.3 (yes, I know it's out of date but it was a test setup which seems to become live and I have not had time to upgrade the thing) which runs a daily process to crunch some logs and do some postGIS processing on them.

Tonight I got this message from my program:

Skipping the copy to disk
Done at Sat Jul 1 02:32:37 2006
Starting vacuum at Sat Jul 1 02:32:41 2006
Can't do the final vacuum and stats! ERROR: could not access status of transaction 1081340514
SQL is <VACUUM ANALYZE;>

Running a vacuum verbose in the afflicted database got this complaint:
DETAIL: 0 dead row versions cannot be removed yet.
There were 19 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: analyzing "pg_catalog.pg_operator"
INFO: "pg_operator": scanned 14 of 14 pages, containing 651 live rows and 0 dead rows; 651 rows in sample, 651 estimated total rows
INFO: vacuuming "public.weekly_log_data"
ERROR: could not access status of transaction 1081340514
DETAIL: could not open file "/data/postgres/psql8_test/pg_clog/0407": No such file or directory

Sure enough, there is no such beast:
[postgres(at)pogo cmnd_logs]$ ls -lt /data/postgres/psql8_test/pg_clog/
total 1716
-rw------- 1 postgres postgres 155648 Jul 1 02:36 0007
-rw------- 1 postgres postgres 262144 Jun 15 02:09 0006
-rw------- 1 postgres postgres 262144 Apr 12 05:27 0005
-rw------- 1 postgres postgres 262144 Mar 12 02:41 0004
-rw------- 1 postgres postgres 262144 Feb 13 00:05 0003
-rw------- 1 postgres postgres 262144 Dec 28 2005 0002
-rw------- 1 postgres postgres 262144 Dec 18 2005 0001

=========================

I can reload the data with some tedium but not effort, but I am wondering if I might have run across a known bug in 8.0.3 ? Are there any things I should look at ? Or should I just start over on my week's logs on a newer, more up to date version ? (it's less than 5 hours of computer time to crunch one day of this stuff,and only a few minutes of operator time, so I can easily cut my losses and run...)

TIA,

Greg Williamson
DBA
GlobeXplorer LLC