Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Currently we need to read pg_control to know the location(LSN) of the
> checkpoint record. This means if pg_control is lost or corrupted, we
> have to give up the database recovery. I think we could start from the
> first WAL segment and read through entire WAL logs to find out the
> latest valid checkpoint record. This may take considerable amount of
> time, but still better than giving up recovery IMO. Any reason we
> cannot do this?
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.
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.
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.
regards, tom lane
