Re: Async Commit, v21 (now: v22)

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Mon, 2007-07-23 at 18:59 -0400, Tom Lane wrote:
>> The shutdown logic in particular seems all wrong; you can't have
>> a process connected to shared memory that is going to outlive the
>> postmaster.

> It seemed to work cleanly when I tested it initially, but I'll take
> another look tomorrow. By version 23 I was going code-blind.

Leave it be for the moment --- I'm working on it now so it'd just be
duplicated effort. I'm inclined though to rebase at least the signal
handling on bgwriter.c; don't like different processes using different
signal interpretations unless there's a good reason for it.

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?

(BTW, in case you can't tell from the drift of my questions, I've
separated the patch into "add background wal writer" and "add async
commit", and am working on the first half.)

regards, tom lane