> I was thinking about what happens when you are performing a PITR using
> log records that contain a crash/recovery/shutdown checkpoint sequence.
> I take it there's no problem there?
I don't really see one. I believe the reason for the StartupCLOG action
is just to make sure that clog doesn't claim that any transactions are
committed that weren't committed according to the WAL, or more precisely
by the portion of WAL we chose to read. Consider PITR stopping short of
the actual WAL end: it would clearly be possible that the current page
of clog says that some "future" transactions are committed, but in our
new database history we don't want them to be so. I think that the code
is also trying to guard against a similar situation in a crash where WAL
has been damaged and can't be read all the way to the end.
Since the PITR slave isn't going to make any changes to clog in the
first place that it isn't told to by WAL, it's hard to see how any
divergence would arise. It could diverge when the slave stops slaving
and goes live, but at that point it's going to do StartupCLOG itself.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment