<div dir="ltr">I think we&#39;ve same problem. When You will implement the client IP address based setting solution, it will solve our problem. Thx!<br><br>In the next steps we would like to migrate some our 2 layer (thick clients - more then 100 users from different IP adressess)  application to the pgpool. If we will same Load Balance  problem, we must set out all of client IP address in the config file one by one. I think is it a little bit difficulty useable.<br>
<br>That reason I would like to suggest maybe the database name setting solution more usable instead of IP address if it possible.<br><br>If You can implement only the client IP based solution, of course we will be very happy too.<br>
<br>Thanks a lot,<br>Csaba<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-12 1:39 GMT+02:00 Tatsuo Ishii <span dir="ltr">&lt;<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>&gt;</span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">&gt; We examined the native replication mode, but our other databases and<br>
&gt; aplications using OIDs, and random values, and I afraid we will be some<br>
&gt; problems. That reason we&#39;re staying in streaming replication mode , and we<br>
&gt; use OTRS without pool in the production area :(<br>
<br>
</div>For random values (i.e. random() function) we will be able to solve<br>
the problem by using similar technique used in handling now(). However<br>
for OID, I have no idea how to solve it.<br>
<div class=""><br>
&gt; Do you planning in the future releases  some extra Load Balance parameters?<br>
&gt; I&#39;m thinking of for example white/black list to turn off/on it on the<br>
&gt; databases, tables, etc.<br>
<br>
</div>I found an interesting TODO related to OTRS:<br>
<br>
<a href="http://www.pgpool.net/mediawiki/index.php/TODO#Ability_to_load_balance_based_on_Client_IP" target="_blank">http://www.pgpool.net/mediawiki/index.php/TODO#Ability_to_load_balance_based_on_Client_IP</a><br>
<br>
The original poster of the TODO item proposed an ablility to control<br>
load balancing based on client IP, rather than database and tables<br>
names. Would this help you if it&#39;s implemented?<br>
<div class="HOEnZb"><div class="h5"><br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
&gt; Thanks for your attention,<br>
&gt; Csaba<br>
&gt;<br>
&gt;<br>
&gt; 2014-04-04 9:13 GMT+02:00 Tatsuo Ishii &lt;<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>&gt;:<br>
&gt;<br>
&gt;&gt; &gt; We&#39;re testing it with your suggested 0 backend weight in the slave. It<br>
&gt;&gt; &gt; working fine without load balancing mode.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; We would like to steer clear of the replication lag problems, that reason<br>
&gt;&gt; &gt; we&#39;re using synchronous replication with remote_write level settings.<br>
&gt;&gt;  But<br>
&gt;&gt; &gt; I see it is not enough.<br>
&gt;&gt;<br>
&gt;&gt; No, it&#39;s not. PostgreSQL&#39;s synchronous replication does not guarantee<br>
&gt;&gt; that on standby sever the log record has been replayed when master<br>
&gt;&gt; returns a commit message. In short, there&#39;s always replication lag.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Can You suggest us an useful solution?<br>
&gt;&gt;<br>
&gt;&gt; As long as you use PostgreSQL&#39;s streaming replication, there&#39;s no<br>
&gt;&gt; solution for replication delay. Possible solution would be:<br>
&gt;&gt;<br>
&gt;&gt; 1) modify your application so that it&#39;s ready for replication lag.<br>
&gt;&gt;<br>
&gt;&gt; 2) use pgpool&#39;s native replication mode.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Thx,<br>
&gt;&gt; &gt; Csaba<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 2014-04-02 1:15 GMT+02:00 Tatsuo Ishii &lt;<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>&gt;:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; Humm.. there&#39;s no error messages in the pgpool log. Maybe the<br>
&gt;&gt; &gt;&gt; replication lag? To make sure that if that is the cause of the<br>
&gt;&gt; &gt;&gt; problem, you could set the slave&#39;s backend weight to 0 and restart<br>
&gt;&gt; &gt;&gt; pgpool-II.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Best regards,<br>
&gt;&gt; &gt;&gt; --<br>
&gt;&gt; &gt;&gt; Tatsuo Ishii<br>
&gt;&gt; &gt;&gt; SRA OSS, Inc. Japan<br>
&gt;&gt; &gt;&gt; English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
&gt;&gt; &gt;&gt; Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt;<br>
</div></div></blockquote></div><br></div>