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

Re: Reliably determining whether the server came up

From: Mischa Sandberg <mischa_sandberg(at)telus(dot)net>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Reliably determining whether the server came up
Date: 2008-11-18 19:06:50
Message-ID: 1227035210.4923124a948e9@legacywebmail.telus.net (view raw or flat)
Thread:
Lists: pgsql-admin
Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Mischa Sandberg <mischa_sandberg(at)telus(dot)net> writes:
> > Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >> I'd bet that the pg_ctl status part is failing.  I get exit status
> 1
> >> from it if there's no server running.
> 
> > Yes, that was part of the problem with the original startup
> script;
> > postmaster hadn't even gotten as far as writing postmaster.pid,
> > I guess. But pg_ctl status returning 1 could also mean that that
> the
> > server had come up, hit a critical problem and exited. Hence my
> problem;
> > this has to detect server failure, reliably, as well.
> 
> You could sleep for a second or so *before* you start looking for
> the
> pidfile.

The systems are under erratic load, due to concurrent
cpu and diskio spikes around start-up time.
1-2 secs is not enough to be a guarantee :-(

Probably not explaining the issues well;
caught between two constraints that aren't really pg's problem;
and wide clusters with automated admin, variable hardware
and spikes of db restarts are no doubt an oddball edge case.
There are workarounds; was hoping for something
clean and obvious (to all but me).
 
Switching back to tailing the log files and moving on.
Thanks everyone.
-- 
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.


In response to

Responses

pgsql-admin by date

Next:From: Tom LaneDate: 2008-11-18 19:44:44
Subject: Re: Reliably determining whether the server came up
Previous:From: Tom LaneDate: 2008-11-18 18:20:25
Subject: Re: Reliably determining whether the server came up

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