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