=?iso-8859-1?q?zhicheng=20wang?= <wang_zc@yahoo.co.uk> writes:
> Jun 1 10:43:55 linux708 postgres[5537]: [30] LOG: database system shutdown was interrupted at 2004-05-28 16:32:08
BST
> Jun 1 10:43:55 linux708 postgres[5537]: [31] LOG: open of /var/lib/pgsql/data/pg_xlog/0000000000000000 (log file 0,
segment0) failed: No such file or directory
> Jun 1 10:43:55 linux708 postgres[5537]: [32] LOG: invalid primary checkpoint record
> Jun 1 10:43:55 linux708 postgres[5537]: [33] LOG: open of /var/lib/pgsql/data/pg_xlog/0000000000000000 (log file 0,
segment0) failed: No such file or directory
> Jun 1 10:43:55 linux708 postgres[5537]: [34] LOG: invalid secondary checkpoint record
> Jun 1 10:43:55 linux708 postgres[5537]: [35] PANIC: unable to locate a valid checkpoint record
Hm, was this a very new Postgres installation? The links to log file
0/0 suggest that it was so new as to not yet have accumulated 16Mb worth
of WAL traffic ... which is not a lot of traffic.
If the links are accurate then what must have happened is that your disk
subsystem lost the physical xlog file.
If the links are not accurate then this suggests corruption of the
pg_control file (i.e., overwriting those fields with zeroes). I find
this idea a bit improbable, though, because the pg_control file has
a CRC64 checksum. It seems very unlikely that corruption of the
pg_control file wouldn't have been noticed and complained of.
In any case, it seems that your upgrade to new disk hardware did not go
as smoothly as you thought. I'd be pretty surprised if the Postgres
files are the only ones that got corrupted --- you'd better look around
and find out what else is broken :-(
regards, tom lane
