Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDtF8-0005gx-N4 for pgsql-admin@arkaria.postgresql.org; Thu, 13 Feb 2014 10:10:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WDtF8-0003ni-7G for pgsql-admin@arkaria.postgresql.org; Thu, 13 Feb 2014 10:10:06 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDtF7-0003nb-1W for pgsql-admin@postgresql.org; Thu, 13 Feb 2014 10:10:05 +0000 Received: from malena.theo-andreou.org ([37.247.48.150]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDtEw-0001qd-32 for pgsql-admin@postgresql.org; Thu, 13 Feb 2014 10:10:03 +0000 Received: from localhost (localhost [127.0.0.1]) by malena.theo-andreou.org (Postfix) with ESMTP id CF7E784503 for ; Thu, 13 Feb 2014 12:09:50 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=theo-andreou.org; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1392286189; x=1393150189; bh=aKBkhYb7VFZqT8MxvdfPSptjFr3M4SMpz/W MfuR5iXw=; b=QOBiq82ap980CL//QJQzhYBJ8DOwswVKDLn3dNiNEKgc1LimIJG 2cKW1vHNFrRi7CX6YciZ0WO+70qneKq6MqGEyJ5027UOMNE+H1wEc0FtIag2pPXC oDzhfKIhDOBuChvHwnrPnAXjvn9XQ6shRPR4F9SCihtbEBERBkZI1gog= X-Virus-Scanned: Debian amavisd-new at malena.theo-andreou.org Received: from malena.theo-andreou.org ([127.0.0.1]) by localhost (malena.theo-andreou.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-Zcduuz2i74 for ; Thu, 13 Feb 2014 12:09:49 +0200 (EET) Received: from [10.100.1.177] (unknown [176.227.224.100]) by malena.theo-andreou.org (Postfix) with ESMTPA id 0C97D806AA; Thu, 13 Feb 2014 12:09:23 +0200 (EET) Message-ID: <52FC99D2.9040706@theo-andreou.org> Date: Thu, 13 Feb 2014 12:09:22 +0200 From: Theodotos Andreou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: pgsql-admin CC: Luca Ferrari , Lou Picciano Subject: Re: Error: pid file is invalid, please manually kill the stale server process. References: <52FB0DBA.2010907@theo-andreou.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Guy thanks for your replies. You are right about the strange I found the problem and is related to the peculiar setup we have on this appliance. PGDATA exists on a mounted partition but we somehow managed to create an older version of PGDATA under the mount point. So sometimes postgres would load the data from the unmounted PGDATA and sometimes from the mounted partition. It' s a pretty unlikely scenario and I burned lots of braincells trying to figure it out. So not really a postgres problem but rather our peculiar setup. On 02/13/2014 10:39 AM, Luca Ferrari wrote: > On Wed, Feb 12, 2014 at 6:59 AM, Theodotos Andreou > wrote: >> I have a weird problem. Sometimes when the machine is restarted, there is no >> $PGDATA/postmaster.pid file. So when I try to restart postgres (service >> postgresql restart) I get the following error: >> > It is not clear what the real problem is. After a machine reboot it is > normal that there is no pid file, meaning a clean shutdown happened > (from the PostgreSQL perspective). After a full start, if the > PostgreSQL process is configured for automatic start, a pid file > should exist. I suspect the problem is related to some ubuntu booting > script that will place the pid file somewhere else from where the > pg_ctl expects to find it. > >> An even scarier side-effect of this is that the data, when this happens, are >> older than the most recent data in the database. >> > This does not make sense at all. How do you know that data is older? > And most notably: is data stable? I mean, could it be some kind of > snapshotting of the database filesystem (as other suggested) or sounds > like a data corruption? > > >> Also postgres is installed on a customer appliance that may experience >> frequent reboots and even abrupt poweroffs! Is postgres in general ideal for >> this situation? Is there an optimal configuration for this scenario? > PostgreSQL is reliable, but even a reliable system can crash when > running on a totally unreliable piece of hardware. I suggest investing > in some good platform to avoid stressing the database with resumes. > However, in such scenario, I will choose a sync of all commits and > short checkpoints, but this will lead to bad performances. > > Luca > > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin