Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 5BA009FA48A for ; Mon, 4 Dec 2006 06:56:44 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 11048-07 for ; Mon, 4 Dec 2006 06:56:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 1C00B9F9F7B for ; Mon, 4 Dec 2006 06:56:38 -0400 (AST) Received: from kingfisher.intern.logix-tt.com (84-72-188-217.dclient.hispeed.ch [84.72.188.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id 641D664C58; Mon, 4 Dec 2006 11:59:27 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 336CF1852EF65; Mon, 4 Dec 2006 11:56:33 +0100 (CET) Message-ID: <4573FEE0.2010406@logix-tt.com> Date: Mon, 04 Dec 2006 11:56:32 +0100 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Travis Whitton Cc: pgsql-sql@postgresql.org Subject: Re: pg_xlog on separate drive References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/40 X-Sequence-Number: 26996 Hi, Travis, Travis Whitton wrote: > Hey guys, sorry if this is slightly OT for this list, but I figure it's > a simple question. If I'm storing pg_xlog on a second non-redundant > drive using the symlink method and the journal drive were to crash, how > difficult is recovery? Will Postgresql simply be able to reinitialize > the journal on a new drive and carry on, or is there more to it than > that? I realize any pending transactions would be lost, but that's not a > huge concern for me because everything I'm importing comes from raw data. The problem is that you risk inconsistency at data and structural level. When the server crashes, it might happen that some pages in the data files are written only partially (because most disks have a much smaller blocksize than the PostgreSQL page size (which is 8k by default)). Now, when the server cannot reply the WAL log, those half-written pages will not be repaired, and your data may be inconsistent at a very low sematic level (duplicate rows, missing rows, broken rows, backend crashes etc.) with no way to repair. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org