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

Reply via email to