Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFPpJ-0008Nv-Sx for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2014 15:09:46 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WFPpJ-0005K3-Ce for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2014 15:09:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFPpI-0005Js-Cj for pgsql-general@postgresql.org; Mon, 17 Feb 2014 15:09:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFPpE-0006Wz-M0 for pgsql-general@postgresql.org; Mon, 17 Feb 2014 15:09:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s1HF9c17016720; Mon, 17 Feb 2014 10:09:39 -0500 From: Tom Lane To: Rob Goethals / SNP cc: "'Albe Laurenz'" , "'pgsql-general@postgresql.org'" Subject: Re: Re: could not create lock file postmaster.pid: No such file or directory, but file does exist In-reply-to: References: Comments: In-reply-to Rob Goethals / SNP message dated "Mon, 17 Feb 2014 14:42:17 +0100" Date: Mon, 17 Feb 2014 10:09:38 -0500 Message-ID: <16719.1392649778@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org Rob Goethals / SNP writes: > When it is trying to startup again this is the logfile output: > ... > 2014-02-15 00:50:05 CET PANIC: could not create file "pg_xlog/xlogtemp.5390": Input/output error The above PANIC is the reason for the abort that happens immediately thereafter. On local storage I'd think this meant disk hardware problems, but since you say you've got the database on an NTFS volume, what it more likely means is that there's a bug in the kernel's NTFS support. Anyway, it's fruitless to try to get Postgres going again until you have a stable filesystem underneath it. Generally speaking, longtime Postgres users are very suspicious of running Postgres atop any kind of networked filesystem. We find that network filesystems are invariably less stable than local ones. NTFS seems likely to be a particularly unfortunate choice from this standpoint, as you get to benefit from Windows' bugs along with Linux's. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general