From owner-freebsd-performance@FreeBSD.ORG Tue Jul 22 09:06:58 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25BCC37B401; Tue, 22 Jul 2003 09:06:58 -0700 (PDT) Received: from search.sparks.net (search.sparks.net [207.5.180.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E2D43FB1; Tue, 22 Jul 2003 09:06:57 -0700 (PDT) (envelope-from dmiller@miningworks.com) Received: by search.sparks.net (Postfix, from userid 100) id E0D95A902; Tue, 22 Jul 2003 12:06:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id D74A2A901; Tue, 22 Jul 2003 12:06:56 -0400 (EDT) Date: Tue, 22 Jul 2003 12:06:56 -0400 (EDT) From: David Miller X-Sender: dmiller@search.sparks.net To: Dan Langille In-Reply-To: <3F1D2208.2124.52B03E6A@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dmiller@miningworks.com X-Mailman-Approved-At: Tue, 22 Jul 2003 16:49:49 -0700 cc: freebsd-database@freebsd.org cc: freebsd-performance@freebsd.org cc: Jason Stone Subject: Re: Tuning for PostGreSQL Database X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 16:06:58 -0000 On Tue, 22 Jul 2003, Dan Langille wrote: > On 21 Jul 2003 at 20:35, Jason Stone wrote: > > > I feel like this is an extremely important point. If softupdates changes > > the semantics of sync(2)/fsync(2), then it absolutely has to be off for a > > postgresql server because postgresql counts on fsync in order to make its > > durability guarantees. > > If this means all FreeBSD-PostgreSQL users need to change their > setup, we need to do something ASAP. I'd first recommend getting the > confirmation from the PostgreSQL team, then adjusting the PostgreSQL > documenation and the FreeBSD port. If softupdates breaks the semantics of sync/fsync it affects a lot more than postgres, it affects every application that manages data on its own. Every other database that doesn't do raw IO would seem to be affected, for example. Before we go off half-cocked, can anyone confirm that softupdates actually does this - reorders/delays sync/fsync - on writes within a file? I had the impression it worked on meta data about files (directory structures) rather than the data within the file itself. --- David