Re: Create and drop temp table in 8.3.4

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.

In response to

Browse pgsql-performance by date

  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)