Re: Create and drop temp table in 8.3.4 - Mailing list pgsql-performance

From Matthew Wakeling
Subject Re: Create and drop temp table in 8.3.4
Date
Msg-id alpine.DEB.1.10.0811111446150.4666@aragorn.flymine.org
Whole thread Raw
In response to Re: Create and drop temp table in 8.3.4  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List 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.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Oddity with view (now with test case)
Next
From: Aidan Van Dyk
Date:
Subject: Re: Create and drop temp table in 8.3.4