Postgres Pro
Downloads
Home   >   mailing lists

Thread: StartupCLOG

StartupCLOG

From
Simon Riggs
Date:
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.comPostgreSQL Training, Services and Support

Re: StartupCLOG

From
Tom Lane
Date:
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

Re: StartupCLOG

From
Simon Riggs
Date:
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.comPostgreSQL Training, Services and Support

Re: StartupCLOG

From
Tom Lane
Date:
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

Re: StartupCLOG

From
Simon Riggs
Date:
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.comPostgreSQL Training, Services and Support