StartupCLOG
I notice that StartupCLOG zeroes out entries later than the nextxid when
we complete recovery in StartupXLOG, reason given is safety in case we
crash.
ISTM that we should also do that whenever we see a Shutdown Checkpoint
in WAL, since that can be caused by a shutdown immediate, shutdown abort
or crash. In each of those cases its possible that we would have the
same conditions as exist at the end of WAL.
Can't see a failure case of importance though, just wanted to flag it up
as a possible. Better a false positive with these types of concern.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
I notice that StartupCLOG zeroes out entries later than the nextxid when
we complete recovery in StartupXLOG, reason given is safety in case we
crash.
ISTM that we should also do that whenever we see a Shutdown Checkpoint
in WAL, since that can be caused by a shutdown immediate, shutdown abort
or crash.
Er, what? The definition of a crash is the *lack* of a shutdown
checkpoint.
regards, tom lane
On Thu, 2008-09-04 at 11:12 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
I notice that StartupCLOG zeroes out entries later than the nextxid when
we complete recovery in StartupXLOG, reason given is safety in case we
crash.ISTM that we should also do that whenever we see a Shutdown Checkpoint
in WAL, since that can be caused by a shutdown immediate, shutdown abort
or crash.Er, what? The definition of a crash is the *lack* of a shutdown
checkpoint.
Yes, but that's not what I'm saying.
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?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
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
On Thu, 2008-09-04 at 12:18 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
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.
OK, cool. I'm just trying to shake out all the possible problems, so
sorry if this one was a false positive.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support