On Thu, Jul 28, 2011 at 5:06 AM, Gavrina, Irina <igavrina@mera.ru> wrote:
> Thank you all for your answers.
>
> I’m using the Red Hat 5 OS. So I have no the ‘upstart’ utility at my
> disposal. Unfortunately.
>
>
>
> Yes, you are right, this is a question of database robustness. You know, If
> any of postgres processes died the postmaster process will again start up
> it. The main worry is if the postmaster process dies (truth be told, I can
> reproduce it only using ‘kill –KILL’, which should be never done, I know)
> and all other processes are up and running. All created connections will go
> on with their work. And it means all db queries will be processed after the
> postmaster died. Am I correct?
It's fairly trivial on any unix platform to implement a cron script
that runs say, once a minute and checks for running postmater. There
are a large number of ways to do that, but grepping ps output for
postmater process is usually a good way to go. From there, you can
attempt starting the service the standard way.
> Is there any risk of losing of data or data corruption in this case?
>
> There is any way to configure the postgres db like ‘if the postmaster
> process died all child processes are stopped’?
>
> Undoubtedly the case of postmaster process dies should be investigated to
> discover the root cause.
exactly. postgres is configured to attempt to restart itself whenever
possible in the event of the crash. The two most likely scenarios I
can think of where postgres suddenly halted are 1. postgres PANIC and
2. being killed from external source, like the infamous OOM killer or
a human, etc. In both cases I think it's preferable to not attempt to
blindly restart the db.
typically if you want postgres to be highly available i'd strongly
encourage you to set up a warm or hot standby and use external
monitoring to do a swichover based on your criteria.
merlin