On Thu, Jul 28, 2011 at 5:06 AM, Gavrina, Irina <igavrina@xxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
