On Thu, May 31, 2012 at 6:19 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > I've looked at this more closely now and I can see that the call to > XLogFlush() that is made from xact_redo_commit_internal() doesn't ever > actually flush WAL, so whether we delay or not is completely > irrelevant. > > So un-agreed. No change required to patch there.
I think Peter's suggestion of forcibly setting the delay to 0 in the startup process is a good one, though. It's one line of code, and if it isn't strictly necessary today, it still seems like good future-proofing. I am not very happy about the idea of renaming commit_* to group_commit_*. It's basically a cosmetic renaming, and breaking existing configuration files for cosmetic purposes does not seem warranted to me, especially when the old and new names are so close. I certainly don't think we can do that in 9.2, now that beta1 has already shipped. Modifying the default contents of postgresql.conf after we've shipped beta has been a historical no-no for reasons that escape me at the moment, but IIRC they're not stupid reasons. Frankly, I think this whole thing should be pushed to 9.3. The commit_delay and commit_siblings knobs suck, but they've sucked for a long time, and it won't kill anybody to wait another release cycle to fix them. We have plenty of more important things queued up for 9.3 already, and I don't believe there's any compelling reason to think that this particular thing needs preferential treatment. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
