Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 1E8E52E0033
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed,  2 Apr 2008 19:44:57 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 17216-10
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed,  2 Apr 2008 19:44:52 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from pih-relay08.plus.net (pih-relay08.plus.net [212.159.14.134])
	by developer.postgresql.org (Postfix) with ESMTP id E71FC2E002D
	for <pgsql-performance@postgresql.org>;
	Wed,  2 Apr 2008 19:44:52 -0300 (ADT)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by pih-relay08.plus.net with esmtp (Exim) id 1JhBhK-00078i-G0
	for pgsql-performance@postgresql.org; Wed, 02 Apr 2008 23:44:50 +0100
Received: from [192.168.0.89] ([192.168.0.89]:2238)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <S154B0> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Wed, 2 Apr 2008 23:49:50 +0100
Message-ID: <47F40D54.2020700@mansionfamily.plus.com>
Date: Wed, 02 Apr 2008 23:48:52 +0100
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Andreas Kostyrka <andreas@kostyrka.org>
CC: Greg Smith <gsmith@gregsmith.com>,  pgsql-performance@postgresql.org
Subject: Re: POSIX file updates
References: <47F1413B.40109@mansionfamily.plus.com>
	<Pine.GSO.4.64.0803311618040.15117@westnet.com>
	<47F3DA25.7050705@mansionfamily.plus.com>
	<1207167852.8299.179.camel@localhost>
In-Reply-To: <1207167852.8299.179.camel@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Plusnet-Relay: 9995e9fea732967eee8eb8a68e46532a
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200804/23
X-Sequence-Number: 29516

Andreas Kostyrka wrote:
> takes over. The thing you worry about is if all data has made it to the
> replication servers, not if some data might get lost in the hardware
> cache of a controller. (Actually, talk to your local computer forensics
> guru, there are a number of way to keep the current to electronics while
> moving them.)
>   
But it doesn't, unless you use a synchronous rep at block level - which 
is why we have SRDF.
Log-based reps are async and will lose committed transactions.  Even if 
you failed over, its
still extra-ordinarily useful to be able to see what the primary tried 
to do - its the only place
the e-comm transactions are stored, and the customer will still expect 
delivery.

I'm well aware that there are battery-backed caches that can be detached 
from controllers
and moved.  But you'd better make darn sure you move all the drives and 
plug them in in
exactly the right order and make sure they all spin up OK with the 
replaced cache, because
its expecting them to be exactly as they were last time they were on the 
bus.

> 3.) a controller cache is an issue if you have a filesystem in your data
> path or not. If you do raw io, and the stupid hardware do cache writes,
> well it's about as stupid as it would be if it would have cached
> filesystem writes.
>   
Only if the OS doesn't know how to tell the cache to flush.  SATA and 
SAS both have that facility.
But the semantics of *sync don't seem to be defined to require it being 
exercised, at least as far
as many operating systems implement it.

You would think hard drives could have enough capacitor store to dump 
cache to flash or the
drive - if only to a special dump zone near where the heads park. They 
are spinning already
after all.

On small systems in SMEs its inevitable that large drives will be shared 
with filesystem use, even
if the database files are on their own slice. If you can allow the drive 
to run with writeback cache
turned on, then the users will be a lot happier, even if dbms commits 
force *all* that cache to
flush to the platters.