Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

On Thu, Jun 28, 2012 at 4:21 AM, Simon Riggs <simon(at)2ndquadrant(dot)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