Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date
Msg-id CAEYLb_UpGt+4WDV_Lquo6F2kr_v3MuY_JvPRcbS1KJ4nji6cBA@mail.gmail.com
Whole thread Raw
In response to Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 31 May 2012 11:19, Simon Riggs <simon@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.

So, does that clear up the question of it being acceptable to add a
delay to every existing XLogFlush() call site? I think so.

Aside from the outstanding question of what to rename
commit_delay/commit_siblings to, and how we might want to reframe
those settings in the docs, I think that's everything.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741
Next
From: Sergey Koposov
Date:
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile