> Since there is not a separate WAL version stamp, introducing one now
> would certainly force an initdb. I don't mind adding one if you think
> it's useful; another 4 bytes in pg_control won't hurt anything. But
> it's not going to save anyone's bacon on this cycle.
Yes, if initdb, that would probably be a good idea.
Imho the initdb now is not a real issue, since all beta testers
know that for serious issues there might be an initdb after beta started.
> At least one of my concerns (single point of failure) would require a
> change to the layout of pg_control, which would force initdb anyway.
Was that the "only one checkpoint back in time in pg_control" issue ?
One issue about too many checkpoints in pg_control, is that you then need
to keep more logs, and in my pgbench tests the log space was a real issue,
even for the one checkpoint case. I think a utility to recreate a busted pg_control
would add a lot more stability, than one more checkpoint in pg_control.
We should probably have additional criteria to time, that can trigger a
checkpoint, like N logs filled since last checkpoint. I do not think
reducing the checkpoint interval is a solution for once in a while heavy activity.
Andreas
