Gilles, It was good to see you in Paris. Now I'm visiting this topic again.
> Le 02/02/2011 00:33, Tatsuo Ishii a écrit : >>>> - IMO we need finer control over which node should be >>>> degenerated. Probably we should have a new flag for each >>>> backend something like this: >>>> >>>> backend_option0 = opt_value where opt_value is one of: >>>> >>>> DEGENRATE_IF_NEEDED: degenrate whenever pgpool-II thinks >>>> needed. This is same behavior of 3.0 or before. >>>> >>>> NEVER_DEGENRATE: never degerate this node. >>>> >>>> DEGENERATE_IF_NOT_PROMOTED: in the master/slave mode, degenrate the >>>> if it's not chosen as NEVER_DEGENRATE: never degerate this nodethe >>>> promoting node. >>>> (I'm not sure this should apply to slony mode) >>> Not sure that we really need all of that. In my opinion, we binary use >>> or not use autorecovery of slaves. What's a reason where we could decide >>> to not recover a particular slave ? >> There are at least two use cases: >> >> 1) For some reasons (for example, protected by other HA solution such >> as heartbeat) we do not want to degenerate the node(probably it's >> the master/primary node). We could have yet another switch >> "never_degenerate_master_node" or some such, but IMO my proposal is >> more general and covers the case. > > In heartbeat solution, the failed node may be dead and the new master > will not be degenerated as it will be the new master. In all case the > follow master only affect the standby nodes. No, I'm talking about pgpool core itself, not follow_master script patches. > Maybe we can have an option to not try recovering the failed node and as > I probably don't saw all the case an option by node allowing or not the > follow the master can bee added too. > >> 2) Mostly read only huge database which has multiple standbys. The >> database is so huge, we don't wan't to recover non promoted >> standbys until the maintenance time. > This is the default case, i-e : no follow. > > > Ok, it will be added to the patch. Thanks for your comments. Ok, I will tackle the new "backend_option" part. I would like to be it included in 3.1. I think backend_option is mostly irrevant your patches anyway, so please revise your patches. We would want major patches arrived before by the end of Feburary. > Between March 1 and 8: pgpool-II 3.1.0 beta1 release. > April 2: pgpool-II 3.1 official release -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
