Simon Riggs <simon@2ndQuadrant.com> writes:
> On 7 June 2012 17:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> 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.
It's not clear to me exactly which parts of the checkpoint process would
need to be duplicated here to be safe. What you're proposing is
basically a partial checkpoint, which would need quite a lot of thought
to be sure it did everything that should be done and nothing that
shouldn't be. And it would be a continuing risk spot for future bugs of
omission.
>> 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.
No, the situation of most concern is where we make some change and then
nothing happens for a very long time. If there's a continuing flow of
updates, then yes a checkpoint will happen ... eventually. Even with
the assumption of continuing updates, the time until a commit is
checkpointed might be vastly longer than the configured checkpoint
interval, and that's an interval in which loss of the WAL log is more
dangerous than it was in any previous release. So basically, this fix
is giving up some hard-to-quantify amount of data security. Per this
thread, there are other ways in which we can fix the useless-checkpoint
problem without giving up any such security.
regards, tom lane