On 7 June 2012 17:27, Tom Lane <[email protected]> wrote: > Simon Riggs <[email protected]> writes: >>> Robert Haas <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
