> editing from pgpoolAdmin, it seems that recovery_timeout has effect on 2 > things: > > 1. the time pgpool waits until all connections are closed > 2. the time it will wait for the node to complete recovery > > it seems that (1) should be effected by client_idle_limit_in_recovery > (which I did not try to edit, its 0)
Currently recovery_timeout affects followings: a) To wait for postmaster properly started b) To wait for all connections from clients are closed before starting the second stage c) Used in pcp_detach_node with gracefull option (So actually recovery_timeout does not affect your mentioning #2.) Anyway I think you are arguing that #b should be affected by client_idle_limit_in_recovery. IMO the behavior of client_idle_limit_in_recovery and #b are different thus we cannot merge them without breaking backward compatibilty. If clients are idle (are not sending any query while recovery) then they are same. But if queries are sent from client while recovery, client_idle_limit_in_recovery does not take effect because client are not idle. On the other hand #b affects even if clients are not idle. Maybe we could interpret the case when client_idle_limit_in_recovery < 0 as "disconnect clients after n seconds even if clients are not idle" in the future pgpool release. What do you think? FYI I include the comment for client_idle_limit_in_recovery in pgpool.conf. # If client_idle_limit_in_recovery is n (n > 0), the client is forced # to be disconnected whenever after n seconds idle (even inside an # explicit transactions!) in the second stage of online recovery. # n = -1 forces clients to be disconnected immediately. # 0 disables this functionality(wait forever). # This parameter only takes effect in recovery 2nd stage. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
