>>> Thanks. I will look into the patch to understand your idea/design >>> rather the code itself because this has a large impact on pgpool-II's >>> overall design. >> >> Just to let you know that the patch itself doesn't affect the overall >> design of PgPool. This was exactly what I want : not modify anything in >> the way it actually works to not break anything and easy adoption of the >> patch. >> >>> Also we need to look at PostgreSQL 9.1 development >>> cycle. It may affect the design of the patch (we want to effectively >>> use PostgreSQL features but in the same time we don't want to break >>> the compatibility to existing PostgreSQL releases). >> >> I don't see what's in Pg 9.1 can affect the patch unless there's a plan >> for cascading replication but I don't think so. Also we will not break >> any PostgreSQL compatibility if this patch only affect streaming >> replication, isn't it ? >> >>> So I want to take enough time to review your patch. >> >> Yes, no problem I've sent a lot of patches these last weeks and I know >> that review can takes more time than coding. >> >>> In the mean time I suggest you to test your patches in other than >>> streaming replication mode to make sure it does not break them. >> >> Ok, I will do the work for this patch as well as the promote any node as >> master patch. Do you think this last one may be useful in other mode >> than streaming replication ? >> >> Whatever we can discuss all of that in Paris next week, I will be very >> pleased to meet you. > > Last weekend I have some time to review your patches. > > I think the basic design of the patches is good. > > - It seems the patch degenerates standbys even if not in streaming > replication mode. I don't think it's a good idea to do it in the > replication mode or raw mode. Not sure for slony mode. > > - 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) > > - myexit() should not be used in fork_follow_child. > > BTW, why do you specify pgpool's IP address in your sample script? IMO > it's obvious that it is localhost.
One more comment. This patch automatically allows to resync non-promoted standby. That's good. But it seems the standby does not stop when follow master script executed. Is it required to invoke pg_ctl in the script? -- 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
