Received: from maia.hub.org (unknown [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 91A2B1337990 for ; Sun, 24 Oct 2010 13:53:29 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 67307-09 for ; Sun, 24 Oct 2010 16:53:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id A239B1336473 for ; Sun, 24 Oct 2010 13:53:21 -0300 (ADT) Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LrGGm-1OTCat167g-013CUg; Sun, 24 Oct 2010 18:53:16 +0200 Message-ID: <4CC46479.2050206@2ndquadrant.com> Date: Sun, 24 Oct 2010 12:53:13 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: James Mansion CC: Kevin Grittner , Bruce Momjian , jd@commandprompt.com, Scott Marlowe , Steve Crawford , pgsql-performance@postgresql.org, Ben Chobot Subject: Re: BBU Cache vs. spindles References: <4CC04EA50200002500036C5E@gw.wicourts.gov> <201010211935.o9LJZTM21744@momjian.us> <4CC0513E0200002500036C68@gw.wicourts.gov> <4CC3E8BF.4090409@mansionfamily.plus.com> In-Reply-To: <4CC3E8BF.4090409@mansionfamily.plus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:jrDtuksEgkMYqto44yhLPgVl0DdoagC2ec9WaWxuWQE m6Z55iU63M2wOX7hu5WH2iuuX18N5tuduNfA4/6SURRd5pWGXu SJMjyG+YPcHX92ooMlJtCgB1cBcsqkRgiMj2Xf71dBTvF5Ppwa xbSmjqmdgcI431YkPxdtazCM0o1sgGW1pSTopRUfYp3lJk4WIA swQmUWcE0fmzRnNuc4r056zAIDfWTlckpq4dV4KLZE= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201010/392 X-Sequence-Number: 40810 James Mansion wrote: > When I looked at the internals of TokyoCabinet for example, the design > was flawed but > would be 'fairly robust' so long as mmap'd pages that were dirtied did > not get persisted > until msync, and were then persisted atomically. If TokyoCabinet presumes that's true and overwrites existing blocks with that assumption, it would land onto my list of databases I wouldn't trust to hold my TODO list. Flip off power to a server, and you have no idea what portion of the blocks sitting in the drive's cache actually made it to disk; that's not even guaranteed atomic to the byte level. Torn pages happen all the time unless you either a) put the entire write into a non-volatile cache before writing any of it, b) write and sync somewhere else first and then do a journaled filesystem pointer swap from the old page to the new one, or c) journal the whole write the way PostgreSQL does with full_page_writes and the WAL. The discussion here veered off over whether (a) was sufficiently satisfied just by having a RAID controller with battery backup, and what I concluded from the dive into the details is that it's definitely not true unless the filesystem block size exactly matches the database one. And even then, make sure you test heavily. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books