| From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |
| Date: | 2012-05-31 11:16:38 |
| Message-ID: | CAEYLb_UpGt+4WDV_Lquo6F2kr_v3MuY_JvPRcbS1KJ4nji6cBA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 31 May 2012 11:19, Simon Riggs <simon(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Koposov | 2012-05-31 11:31:56 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Previous Message | Robert Haas | 2012-05-31 11:14:12 | Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741 |