From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-patches(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us> |
Subject: | Re: Async Commit, v21 (now: v22) |
Date: | 2007-07-24 06:28:03 |
Message-ID: | 1185258483.4263.28.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Mon, 2007-07-23 at 21:06 -0400, Tom Lane wrote:
> I came across another point worthy of mention: as given, the patch turns
> XLogWrite's "flexible write" logic into dead code, because there are no
> callers that pass flexible = true. We could rip that out, but it seems
> to me there's still some value to it under high load conditions ("high
> load" meaning we fill multiple wal pages per wal_writer_delay). What
> I'm inclined to do is modify XLogBackgroundFlush so that it uses
> flexible = true when it's flushing whole pages. The downside to that
> is that it could take as many as three walwriter cycles, instead of two,
> to guararantee an async commit is down to disk:
> * first write/flush stops at buffer wraparound point
> * second one stops at last complete page
> * third finally is certain to write any remaining commit record
> This seems like no big problem to me, but does anyone want to object?
Sure, that would work.
The logic is still the same: we only need the last flush if there is a
pause in the flow of transactions, so the majority of transactions will
still reach disk in one wal_writer_delay.
Most of the time the first and second phases are performed in just one
write anyway. It's just the few times we're next to the circular buffer
wrap point we would need this.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-07-24 06:41:39 | Re: Reviewing new index types (was Re: [PATCHES]Updatedbitmap indexpatch) |
Previous Message | Simon Riggs | 2007-07-24 06:14:15 | Re: Async Commit, v21 (now: v22) |