Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 57796632FDF for ; Mon, 23 Feb 2009 05:14:30 -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 64381-01 for ; Mon, 23 Feb 2009 05:14:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.saga.it (host85-166-static.47-88-b.business.telecomitalia.it [88.47.166.85]) by mail.postgresql.org (Postfix) with ESMTP id BB0B063279C for ; Mon, 23 Feb 2009 05:14:23 -0400 (AST) Received: from [10.77.1.47] ([10.77.1.47]) by srvmailbs.bs.local (Lotus Domino Release 6.5.4) with ESMTP id 2009022309591042-10016 ; Mon, 23 Feb 2009 09:59:10 +0100 Message-ID: <49A2655E.3080406@saga.it> Date: Mon, 23 Feb 2009 09:59:10 +0100 From: Nicola Mauri User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kenneth Marshall CC: pgsql-admin@postgresql.org Subject: Re: Crash with data corruption under Windows References: <499EBEF0.1010408@saga.it> <20090220160313.GL14957@it.is.rice.edu> In-Reply-To: <20090220160313.GL14957@it.is.rice.edu> X-MIMETrack: Itemize by SMTP Server on saga_bs1/saga(Release 6.5.4|March 27, 2005) at 23/02/2009 09.59.10, Serialize by Router on Front_Bs/saga at 02/23/2009 10:15:30 AM, Serialize complete at 02/23/2009 10:15:30 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200902/191 X-Sequence-Number: 31412 > On Fri, Feb 20, 2009 at 03:32:16PM +0100, Nicola Mauri wrote: > >> We run into the following issue with Windows 2003 and Postgres 8.2.6 while >> database was running: >> >> FATAL: "pg_tblspc/16405/37638" is not a valid data directory >> DETAIL: File "pg_tblspc/16405/37638/PG_VERSION" is missing. >> ERROR: could not open relation 16405/37638/2661: No such file or >> directory >> ERROR: could not open relation 16405/37638/2659: No such file or >> directory >> ERROR: could not write block 4 of relation 16405/37638/37656: Permission >> denied >> CONTEXT: writing block 4 of relation 16405/37638/37656 >> ... >> WARNING: could not write block 4 of 16405/37638/37656 >> DETAIL: Multiple failures --- write error may be permanent. >> >> This happened 4 times in the last few months! Usually after the crash >> datafiles appear to be corrupted, but in some other cases they completely >> disappear from the filesystem (tablespace directory is empty) and we have >> to recreate the entire db from the last dump. >> >> No suspicious activities have been detected on the server (unauthorized >> accesses, anti-virus intervention) and information about disappeared files >> cannot be found using an undelete utilities. Disk hardware is healthy and >> no other part of the filesystem seems to be affected by such strange >> deletions (several applications, including an oracle database, are >> correctly running on the server). >> >> Since the problem seems involving only directories containing tablespaces >> (stored on local partition E:\) we are pointing our attention to "Reparse >> Point" and "NTFS Junction" mechanism. >> >> Could be there issues in those features? >> >> Thanks in advance, >> Nicola Mauri >> >> > I did not check the release note, but you do realize that you are > 6 releases back from the latest stable 8.2 version. Maybe an upgrade > would help. > > Cheers, > Ken > Yes, we now upgraded to 8.2.11, but not sure if this will help and prevent data losses in the future. So we wonder if someone has some hints. thanks Nicola