> Is it worth worrying about? I don't recall that we've ever heard of a
> loss-of-pg_control failure in the field. Certainly it *could* happen,
> but I can gin up plenty of implausible scenarios where scanning pg_xlog
> for a checkpoint would give the wrong answer as well. (Our habit of
> recycling xlog segments by renaming them makes us vulnerable to
> confusion over filenames, for example.) Since pg_control is
> deliberately kept to less than one disk block and is written only once
> per checkpoint, you'd have to be really unlucky to lose it anyway.
If my memory is corrent, some of my customers or member of local
mailing list has reported that they could not start postmaster because
it failed in the middle of the starting up process. And two or three
said they lost pg_control for unknown reason. I'm not sure the trouble
was only with pg_control or not though.
Regarding the file name of xlog segments, I think we could read the
XLogPageHeader and could easily determine which is the oldest and
which one is the recyled one.
> Also, you can rebuild pg_control from scratch using pg_resetxlog,
> so loss of pg_control is not in itself worse than loss of the pg_xlog
> directory.
One annoying thing with pg_resetxlog is that we need to use -f option
if it cannot read pg_control and have to give it haphazard
OID. Moreover After using pg_resetxlog, we have to take a fulldump and
reconsutruct the database. This will lead very long down time if the
data is huge. So I don't think pg_resetxlog is the best solution in
this case.
> My feeling is that pg_clog is by far the most fragile part of the
> logging mechanism at the moment: two very critical bits per transaction
> and essentially no error checking. If you want to improve reliability,
> think about how to make clog more robust.
What's wrong with improving one of fragile parts of the system?
--
Tatsuo Ishii
