On Thu, Jun 28, 2012 at 4:21 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Let's put this in now, without too much fiddling. There is already a > GUC to disable it, so measurements can be made to see if this causes > any problems. > > If there are problems, we fix them. We can't second guess everything.
Fair enough. >> 2. Should we rename the GUCs, since this patch will cause them to >> control WAL flush in general, as opposed to commit specifically? >> Peter Geoghegan and Simon were arguing that we should retitle it to >> group_commit_delay rather than just commit_delay, but that doesn't >> seem to be much of an improvement in describing what the new behavior >> will actually be, and I am doubtful that it is worth creating a naming >> incompatibility with previous releases for a cosmetic change. I >> suggested wal_flush_delay, but there's no consensus on that. >> Opinions? > > Again, leave the naming of that for later. The idea of a rename came > from yourself, IIRC. Deciding on a name is not such a hard thing that leaving it till later solves any problem. Let's just make a decision and be done with it. >> The XLByteLE test four lines from the bottom should happen before we >> consider whether to sleep, because it's possible that we'll discover >> that our flush request has already been satisfied and exit without >> doing anything, in which case the sleep is a waste. The attached >> version adjusts the logic accordingly. > > I thought there already was a test like that earlier in the flush. > > I agree there needs to be one. There are several of them floating around; the point here is just to make sure that the sleep is after all of them. -- 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
