Hi > -----Original Message----- > From: ext Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Tuesday, June 09, 2009 9:20 PM > To: Kolb, Harald (NSN - DE/Munich) > Cc: Robert Haas; Greg Stark; Simon Riggs; Fujii Masao; > pgsql-hackers@postgresql.org; Czichy, Thoralf (NSN - FI/Helsinki) > Subject: Re: [HACKERS] postmaster recovery and automatic > restart suppression > > "Kolb, Harald (NSN - DE/Munich)" <harald.k...@nsn.com> writes: > > If you don't want to see this option as a GUC parameter, would it be > > acceptable to have it as a new postmaster cmd line option ? > > That would make two kluges, not one (we don't do options that are > settable in only one way). And it does nothing whatever to address > my objection to the concept. > > regards, tom lane >
First point is understood. Second point needs further discussion: The recovery and restart feature is an excellent solution if the db is running in a standalone environment and I understand that this should not be weakened. But in a configuration where the db is only one resource among others and where you have a central supervisor, it's problematic. Then this central instance observes all the resources and services and decides what to do in case of problems. It's not up to the resource/service to make it's own decision because it's only a piece of the cake and doesn't has the complete view to the whole situation. E.g. the behaviour might be different if the problems occurr during an overload situation or if you already have hints to HW related problems or if you are in an upgrade procedure and the initial start fails. An uncontrolled and undetected automatic restart may complicate the situation and increase the outage time. Thus it would be helpful to have the possibility of a very fast failure detection (SIGCHLD in controlling instance) and to avoid wasteful cleanup procedures. If the db is embedded in a management (High Availability) environment, this option will be helpful in general, independent if you have a cluster or a single node. But in a cluster environment it would be more important to have this switch, because you always will have this management instance, the cluster software. And of course the main reason of a cluster is to switch over when it makes sense to do so. And one good reason to realy do it is when a central instance like the db on the primary side crashes. At least the user should have the possibility to decide this, but this would require that PostgreSQL constructively supports this situation. Regards, Harald. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers