> On Mon, May 9, 2011 at 7:07 PM, Tatsuo Ishii <[email protected]> wrote: > >> >> You mean connection to backend? Yes, anytime child re-open the >> >> connection automatically if neccessary (and possible). It's a >> >> transparent processing for clients. >> >> >> >> >> > In that case, and still with the objective of minimizing the memory >> > footprint, does this seem like a good compromise: >> > >> > child_life_time = 1800 >> > connection_life_time = 300 >> > >> > If the server is idle, the child will exit / respawn after 30 min, but >> after >> > 5 min it will drop the connection to the backend, meaning that an idle >> child >> > would only be connected to the backend 1/6th of the time. Is that >> correct? >> >> Yes, correct. >> >> > Do you see any potential issues with such a setup? >> >> If a client keeps on connecting to pgpool-II, the above settings will >> not work since they are only activated after the client disconnects to >> pgpool-II. If you want to force idle clients be disconnected, you >> could turn on this: >> >> # If client_idle_limit is n (n > 0), the client is forced to be >> # disconnected whenever after n seconds idle (even inside an explicit >> # transactions!) >> # 0 means no disconnect. >> client_idle_limit = 0 >> >> > What is considered idle?
No packet has been sent from the client last client_idle_limit seconds. This does not include the case while the client sent a query and wait for the result. For example, waiting for a lock is acquired. > I guess the "even inside an explicit transaction" > scares me, as "inside a transaction" doesn't seem "idle". Why? A sloppy client always can just send "BEGIN" then do nothing. Idle is idle, right? -- 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
