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.