Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 1E31364FD34 for ; Thu, 6 Nov 2008 20:04:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 76972-06 for ; Thu, 6 Nov 2008 20:04:00 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mail.postgresql.org (Postfix) with ESMTP id 8713964FCDA for ; Thu, 6 Nov 2008 20:04:00 -0400 (AST) Received: by wa-out-1112.google.com with SMTP id j4so478085wah.19 for ; Thu, 06 Nov 2008 16:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dYgo8vR3JZBOCXCAAEv5hCPVtIfrfgxc+QJJtY2+S9U=; b=D3nofv1fCjYCF3/ZDbzr9mRvNETRkAcIZRYJ1mXMc2SJATjPtXJPaXB5s6bxmAuqib N/QK6y3TEcqbahn6O8azAN0YChz4VG9NL2suV647/QiPtCoX0f9R1hwuNPNR9X4ssyme aF7sbVA6biPAps28dNSSqQs8AuRq8A/sTuWYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xUy8yhVRZR9hrNuZImuK1bBWMY88wRJltvWFB+i/R3rw3b2hUqaR5EE028Fk8D4oQS XycM4ydwVGZP1O5aqGGeaHJCX4WIjFKIAWXmRljFIrFwOX4d8vU7Esi/JHYIV9WfzlSn ieUM0vNI5kq0ALR/CnKan9oOEgoRwdY6FxfVY= Received: by 10.114.159.5 with SMTP id h5mr1085538wae.190.1226016239038; Thu, 06 Nov 2008 16:03:59 -0800 (PST) Received: by 10.114.39.11 with HTTP; Thu, 6 Nov 2008 16:03:58 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 17:03:58 -0700 From: "Scott Marlowe" To: "Kevin Grittner" Subject: Re: Create and drop temp table in 8.3.4 Cc: jd@commandprompt.com, pgsql-performance@postgresql.org, "Scott Carey" In-Reply-To: <49132383.EE98.0025.0@wicourts.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4911957A.EE98.0025.0@wicourts.gov> <4911D4DB.EE98.0025.0@wicourts.gov> <4912EAFF.EE98.0025.0@wicourts.gov> <1225999071.1204.14.camel@jd-laptop.pragmaticzealot.org> <4912F29E.EE98.0025.0@wicourts.gov> <49131C67.EE98.0025.0@wicourts.gov> <49132383.EE98.0025.0@wicourts.gov> X-Archive-Number: 200811/45 X-Sequence-Number: 31776 On Thu, Nov 6, 2008 at 4:04 PM, Kevin Grittner wrote: >>>> "Scott Marlowe" wrote: >> On Thu, Nov 6, 2008 at 3:33 PM, Kevin Grittner >> wrote: >>>>>> "Scott Marlowe" wrote: >>>> I am pretty sure that with no write barriers that even a BBU >>> hardware >>>> caching raid controller cannot guarantee your data. >>> >>> That seems at odds with this: >>> >>> http://oss.sgi.com/projects/xfs/faq.html#wcache_persistent >>> >>> What evidence to you have that the SGI XFS team is wrong? >> >> 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.