Skip site navigation (1) Skip section navigation (2)

Re: Async Commit, v21 (now: v22)

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-07-24 06:41:39
Subject: Re: Reviewing new index types (was Re: [PATCHES]Updatedbitmap indexpatch)
Previous:From: Simon RiggsDate: 2007-07-24 06:14:15
Subject: Re: Async Commit, v21 (now: v22)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group