Skip site navigation (1) Skip section navigation (2)

Re: postmaster.pid

From: Joerg Hessdoerfer <Joerg(dot)Hessdoerfer(at)sea-gmbh(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: postmaster.pid
Date: 2004-08-26 14:54:52
Message-ID: 200408261654.52376.Joerg.Hessdoerfer@sea-gmbh.com (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
On Thursday 26 August 2004 16:25, Tom Lane wrote:
[...]
> The real point here is that the behavior has to be to default to
> failure, not success.  The worst case if we fail incorrectly is that a
> small amount of manual intervention is needed to start the postmaster,
> ie, remove the lockfile and try again.  The worst (and very probable)
> case if we succeed incorrectly is extensive, unrecoverable data
> corruption.  We must *never* have multiple postmasters running against
> the same data directory.  So taking an attitude of "prove that there is
> a working postmaster out there" is quite backwards.  You have to think
> in terms of "prove that there isn't".
[...]

Of course you're right, as always ;-)  Data integrity has to be the absolute 
priority, 'twas too early in the morning.

I just got sidetracked because of spurious 'why does our XXX not work?' 
questions of people who let their production DB servers (this is for 
industrial manufacturing processes, like laser welding) running in the 
machine floor, and whose boxes get shot down every now and then, and 
sometimes... pg doesn't start. Then the 'small amount of manual intervention' 
sometimes is not so small - depending on OS and/or configuration, or even 
remote access to the box. Mind you, these are mostly non-computer savvy 
people, and those sometimes get upset when 'the system does not startup 
correctly' - because that means they can't currently produce a car!

We're working around this by adding a shell script that removes 
'postmaster.pid' as last action at system *shutdown*, so we can tell them to 
'restart the machine', and everything usually just works fine. But, a 
postmaster internal but safe mechanism would be great. Just daydreaming...

Greetings,
 Jörg
-- 
Leading SW developer  - S.E.A GmbH
Mail: joerg(dot)hessdoerfer(at)sea-gmbh(dot)com
WWW:  http://www.sea-gmbh.com

In response to

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2004-08-26 14:56:53
Subject: Re: Service startup delay
Previous:From: Andrew DunstanDate: 2004-08-26 14:42:32
Subject: Re: [PATCHES] postmaster.pid

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group