Re: Avoiding adjacent checkpoint records

On 6 June 2012 20:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> In commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724, Simon modified the
> rule for when to skip checkpoints on the grounds that not enough
> activity has happened since the last one.  However, that commit left the
> comment block about it in a nonsensical state:
>
>    * If this isn't a shutdown or forced checkpoint, and we have not switched
>    * to the next WAL file since the start of the last checkpoint, skip the
>    * checkpoint.  The idea here is to avoid inserting duplicate checkpoints
>    * when the system is idle. That wastes log space, and more importantly it
>    * exposes us to possible loss of both current and previous checkpoint
>    * records if the machine crashes just as we're writing the update.
>    * (Perhaps it'd make even more sense to checkpoint only when the previous
>    * checkpoint record is in a different xlog page?)
>
> The new code entirely fails to prevent writing adjacent checkpoint
> records, because what it checks is the distance from the previous
> checkpoint's REDO pointer, not the previous checkpoint record itself.

You were completely involved in the original discussion of this, as
were others.
I made the change to use the redo pointer at your request. So when you
say Simon did this, what you mean is Simon acted according to group
consensus on an agreed feature.

How come this is a valid discussion? Why does making changes here make
sense when other changes are said to destabilise the code and delay
release?

Should I revisit all the things others have done that I disagree with as well?

No, I should not. Nor should we be trawling through changes made by me either.

I'll look some more at this, but you should consider why this thread
even exists.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services