Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Sure: the advantage is that the backends (ie, user query processing) >> don't get blocked on fsync's. This is not really different from the >> rationale for having the bgwriter.
> I'm puzzled though. How do they not get blocked on fsyncs? They can't proceed > past their commit until the fsync happens whether they do it themselves or the > walwriter does it. Sure, they'll block on an fsync when they commit. Even then, the walwriter can be an advantage if it's already flushed previous WAL blocks: writing and flushing one page of WAL is faster than writing and flushing a lot of pages, no? >> It's probably most useful for large transactions, which up to now generally >> had to stop and flush the WAL buffers every few pages worth of WAL output. > That could be useful though the backend doesn't have to fsync when it writes > out those buffers, does it? A lot of systems seem to favor synchronous write methods for WAL, in which you effectively *do* fsync when you write. There's also the problem that if you have to write a dirty buffer, you must first ensure WAL is fsync'd up through its LSN. (So to some extent this is also offloading work from the bgwriter.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly