Simon Riggs <si...@2ndquadrant.com> writes: > On 7 June 2012 17:27, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers