Re: Async Commit, v21 (now: v22) - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 1185258483.4263.28.camel@ebony.site
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Async Commit, v21 (now: v22)
Next
From: Florian Weimer
Date:
Subject: Re: Async Commit, v21 (now: v22)