From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Create and drop temp table in 8.3.4 |
Date: | 2008-11-11 14:52:50 |
Message-ID: | alpine.DEB.1.10.0811111446150.4666@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 6 Nov 2008, Scott Marlowe wrote:
> Without write barriers, the second we call an fsync it returns true.
>
> But that's assuming write barriers work as I understand them.
Write barriers do not work as you understand them.
Calling fsync always blocks until all the data has made it to safe
storage, and always has (barring broken systems). Write barriers are meant
to be a way to speed up fsync-like operations. Before write barriers, all
the system could do was call fsync, and that would cause the operating
system to wait for a response from the disc subsystem that the data had
been written before it could start writing some more stuff. Write
barriers provide an extra way of telling the disc "Write everything before
the barrier before you write anything after the barrier", which allows the
operating system to keep stuffing data into the disc queue without having
to wait for a response.
So fsync should always work right, unless the system is horribly broken,
on all systems going back many years.
Matthew
--
I'd try being be a pessimist, but it probably wouldn't work anyway.
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2008-11-11 15:07:53 | Re: Create and drop temp table in 8.3.4 |
Previous Message | Tom Lane | 2008-11-11 03:20:09 | Re: Oddity with view (now with test case) |