On 06/21/2010 10:32 PM, Tatsuo Ishii wrote: >> On 06/21/2010 10:16 PM, Tatsuo Ishii wrote: >>>> On 06/21/2010 08:31 PM, Tatsuo Ishii wrote: >>>>>> As far as I know, pgpool-II waits for [all] backends to commit the SQL >>>>>> statements (under replication mode) before returning to the client, >>>>>> right? This means that if, for example, one of the backends is very busy >>>>>> (100% CPU, etc.), pgpool will experience a delay and so will the >>>>>> application. Is this correct? >>>>> >>>>> Correct. This is a known behavior of all synchronous replication >>>>> systems. This ensures that committed data (from client's point of >>>>> view) is actually committed to all backends. >>>> >>>> Is there a way to set a timeout for this? It would be interesting the >>>> possibility of setting a timeout, and if it expires, the possibility of >>>> automatically degenerate the backend. >>> >>> I think you could use PostgreSQL's statement_timeout for this purpose. >> >> This will automatically degenerate the backend and restore normal >> services? > > No. > >> If a backend has problems, it is interesting that pgpool-II be >> able to degenerate it and restore normal services by using the other >> available backends. > > I'm not sure just taking long time to execute a query is the trigger > of degeneration.
This may be optional and disabled by default, but it would certainly be very useful. > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese: http://www.sraoss.co.jp -- Ramon de Carvalho Valle RISE Security E-Mail: ra...@risesecurity.org _______________________________________________ Pgpool-general mailing list Pgpool-general@pgfoundry.org http://pgfoundry.org/mailman/listinfo/pgpool-general