Re: Avoiding adjacent checkpoint records

On 7 June 2012 17:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> I know of real customers who would have suffered real data loss
>>>> had this code been present in the server version they were using.
>
>> If that is the concern, then its a one line fix to add the missing clog flush.
>
> To where, and what performance impact will that have?

To the point where we decide to skip the other parts of the
checkpoint. How would that cause a performance impact exactly? It's
less work than the original behaviour would be.

>> The other suggestions I've skim read seem fairly invasive at this
>> stage of the release.
>
> The issue here is that we committed a not-very-well-thought-out fix
> to the original problem.  I think a reasonable argument could be made
> for simply reverting commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724
> and postponing any of these other ideas to 9.3.  The useless-checkpoints
> problem has been there since 9.0 and can surely wait another release
> cycle to get fixed.  But I concur with Robert that changing the system
> behavior so that checkpointing of committed changes might be delayed
> indefinitely is a high-risk choice.

Clearly, delaying checkpoint indefinitely would be a high risk choice.
But they won't be delayed indefinitely, since changes cause WAL
records to be written and that would soon cause another checkpoint.

Robert has shown a bug exists, so it should be fixed directly,
especially if we believe in least invasive changes. If
not-fixing-the-actual-bug happened before, its happening again here as
well, with some poor sounding logic to justify it.

Please act as you see fit.

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