Skip site navigation (1) Skip section navigation (2)

Re: Create and drop temp table in 8.3.4

From: "David Rees" <drees76(at)gmail(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, jd(at)commandprompt(dot)com, pgsql-performance(at)postgresql(dot)org, "Scott Carey" <scott(at)richrelevance(dot)com>
Subject: Re: Create and drop temp table in 8.3.4
Date: 2008-11-07 02:21:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, Nov 6, 2008 at 4:03 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Thu, Nov 6, 2008 at 4:04 PM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> wrote:
>>> Without write barriers in my file system an fsync request will
>>> be immediately returned true, correct?
>> Not as I understand it; although it will be pretty fast if it all fits
>> into the battery backed cache.
> OK, thought exercise time.  There's a limited size for the cache.
> Let's assume it's much smaller, say 16Megabytes.  We turn off write
> barriers.  We start writing data to the RAID array faster than the
> disks can write it.  At some point, the data flowing into the cache is
> backing up into the OS.  Without write barriers, the second we call an
> fsync it returns true.  But the data's not in the cache yet, or on the
> disk.  Machine crashes, data is incoherent.
> But that's assuming write barriers work as I understand them.

Let's try to clear up a couple things:

1. We are talking about 3 different memory caches in order from low to high:
Disk cache, Controller cache (BBU in this case) and OS cache.

2. A write barrier instructs the lower level hardware that commands
issued before the barrier must be written to disk before commands
issued after the barrier. Write barriers are used to ensure that data
written to disk is written in such a way as to maintain filesystem
consistency, without losing all the benefits of a write cache.

3. A fsync call forces data to be synced to the controller.

This means that whenever you call fsync, at the very minimum, the data
will have made it to the controller. How much further down the line
will depend on whether or not the controller is in WriteBack or
WriteThrough mode and whether or not the disk is also caching writes.

So in your example, if the OS is caching some writes and fsync is
called, it won't be returned until at a minimum the controller has
accepted all the data, regardless of whether or not write barriers are

In theory, it should be safe to disable write barriers if you have a
BBU because the BBU should guarantee that all writes will eventually
make it to disk (or at least reduce the risk of that not happening to
an acceptable level).


In response to


pgsql-performance by date

Next:From: Віталій ТимчишинDate: 2008-11-07 09:14:01
Subject: Re: PostgreSQL OR performance
Previous:From: Scott MarloweDate: 2008-11-07 00:03:58
Subject: Re: Create and drop temp table in 8.3.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group