Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E70B51336DB6 for ; Thu, 28 Oct 2010 18:26:35 -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 23312-05 for ; Thu, 28 Oct 2010 21:26:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 806021335B36 for ; Thu, 28 Oct 2010 18:26:27 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o9SLQHuk026349; Thu, 28 Oct 2010 17:26:17 -0400 (EDT) To: James Mansion cc: Greg Smith , Kevin Grittner , Bruce Momjian , jd@commandprompt.com, Scott Marlowe , Steve Crawford , pgsql-performance@postgresql.org, Ben Chobot Subject: Re: BBU Cache vs. spindles In-reply-to: <4CC9DE0F.50401@mansionfamily.plus.com> References: <4CC04EA50200002500036C5E@gw.wicourts.gov> <201010211935.o9LJZTM21744@momjian.us> <4CC0513E0200002500036C68@gw.wicourts.gov> <4CC3E8BF.4090409@mansionfamily.plus.com> <4CC46479.2050206@2ndquadrant.com> <16724.1287952819@sss.pgh.pa.us> <4CC9DE0F.50401@mansionfamily.plus.com> Comments: In-reply-to James Mansion message dated "Thu, 28 Oct 2010 21:33:19 +0100" Date: Thu, 28 Oct 2010 17:26:17 -0400 Message-ID: <26348.1288301177@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/564 X-Sequence-Number: 40982 James Mansion writes: > Tom Lane wrote: >> The other and probably worse problem is that there's no application >> control over how soon changes to mmap'd pages get to disk. An msync >> will flush them out, but the kernel is free to write dirty pages sooner. >> So if they're depending for consistency on writes not happening until >> msync, it's broken by design. (This is one of the big reasons we don't >> use mmap'd space for Postgres disk buffers.) > Well, I agree that it sucks for the reason you give - but you use > write and that's *exactly* the same in terms of when it gets written, > as when you update a byte on an mmap'd page. Uh, no, it is not. The difference is that we can update a byte in a shared buffer, and know that it *isn't* getting written out before we say so. If the buffer were mmap'd then we'd have no control over that, which makes it mighty hard to obey the WAL "write log before data" paradigm. It's true that we don't know whether write() causes an immediate or delayed disk write, but we generally don't care that much. What we do care about is being able to ensure that a WAL write happens before the data write, and with mmap we don't have control over that. regards, tom lane