Hi tom,
the database is on a mountable volume. So that could be our problem.
Reading your comments i would like to know if an automatic initdb on
postmaster startup can be disabled.
Is this possible?
We would receive a severe postmaster error, but this would be expected
behaviour in case that the mountable volume is temporarily unavailable.
Volker
It looks to me like pg_control is quite out of sync with the files in
pg_xlog. pg_control claims to have checkpointed as recently as 16-Aug
but there is no file newer than 7-Aug in pg_xlog. The other thing that
is strange is that the filename numbers in pg_xlog correspond to WAL
locations much higher than what pg_control claims is the end of WAL.
Is $PGDATA kept on a dismountable volume (ie, not the root disk)?
If so it might be a good idea to unmount the volume and look to see
if there's anything under the mount point. I recall having seen
corruption that came from trying to start Postgres before the $PGDATA
disk had been mounted --- the initscript happily initdb'd a new database
under the mount-point directory, and then when the main disk did come up
things were badly hosed because the server was working with a pg_control
in memory that was completely out of sync with everything else. This
looks a bit like that might have happened here.
As far as running pg_resetxlog goes, there is advice about setting the
parameters in recent releases' documentation; try
http://developer.postgresql.org/docs/postgres/app-pgresetxlog.html
for the latest. (Some of the parameters mentioned don't exist in
7.4; just ignore 'em.) I'm afraid though that you may have actual
database corruption. If so pg_resetxlog won't fix it.
