On Fri, 14 Oct 2016 09:59:04 +0200
"Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Jehan-Guillaume de Rorthais <j...@dalibo.com> schrieb am 13.10.2016 um
> >>> 23:56 in  
> Nachricht <20161013235606.007018eb@firost>:
> [...]
> > As far as I know, the pgsql resource agent create such a lock file on 
> > promote
> > and delete it on graceful stop. If the PostgreSQL instance couldn't be 
> > stopped
> > correctly, the lock files stays and the RA refuse to start it the next
> > time.  
> As a note: We once had the case of a very old stale PID file, where a valid
> start was denied, because the PID existed, but belonged to a completely
> different process in the meantime (on a busy server). That's why stale PID
> files should be deleted; specifically they shouldn't survive a reboot ;-)

As far as I understand this logic, it has changed now. The PID file of
PostgreSQL contains the PID **and** shmid created by the last postmaster

During a fresh start, if the postmaster.pid file exists, it checks if the PID
AND the shmid still exist on the system and some processes are still connected
to it.

See CreateLockFile in src/backend/utils/init/miscinit.c:


> You can conclude from a missing PID that the process is not running with that
> PID, but you cannot conclude from an existing PID that it's still the same
> process ;-)

At least, what I just described checks if the existing PID is owned by the same
user using a kill -0.

Cheers :)

Users mailing list: Users@clusterlabs.org

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Reply via email to