<div dir="ltr">There is another part in docs:<div><br><div><a href="http://www.pgpool.net/docs/latest/pgpool-en.html">http://www.pgpool.net/docs/latest/pgpool-en.html</a></div><div>In an explicit transaction:Transaction starting commands such as BEGIN are sent to the primary node.Following SELECT and some other queries that can be sent to both primary or standby are executed in the transaction or on the standby node.Commands which cannot be executed on the standby such as INSERT are sent to the primary. After one of these commands, even SELECTs are sent to the primary node, This is because these SELECTs might want to see the result of an INSERT immediately. This behavior continues until the transaction closes or aborts.</div></div><div><br></div><div>It looks like pgpool treats all stored functions as non writing in this scenario.</div></div><br><div class="gmail_quote">вт, 21 апр. 2015 г. в 12:05, Сергей Мелехин &lt;<a href="mailto:cpro29a@gmail.com">cpro29a@gmail.com</a>&gt;:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div>Our test server is relatively slow, and there are some lags in replication between master and slave sometimes. We are using pgpool 3.3.4 in load balancing mode to mimic our production environment.</div><div>Some unit tests are making some changes in database (calling stored functions) and immediately check them issuing select queries. Sometimes they fail not finding records they have just inserted.</div><div>Judging by this verse in documentation:</div><div><p style="padding-left:15px;padding-right:15px;margin-left:25px;margin-right:25px;color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:normal">For a query to be load balanced, all the following requirements must be met:</p><ul style="margin-left:40px;color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:normal"><li style="list-style:square;color:rgb(102,51,51)">PostgreSQL version 7.4 or later</li><li style="list-style:square;color:rgb(102,51,51)"><b>the query must not be in an explicitly declared transaction (i.e. not in a BEGIN ~ END block)</b></li></ul></div><div>we decided that putting whole test in transaction block will avoid load balancing for such test, but it looks like that no matter being in transaction, selects are replicated to slave and dont find desired data because of replication lags. This errors are present when we use stored functions, when we use explicit DML, selects inside transaction are not replicated. Function names are not included in white or black list in pgpool.conf.</div><div><br></div><div>Is it normal behaviour, or is it a bug?</div><div><br></div><div>I include simple test, it fails in our slow replication environment.</div><div>You&#39;ll need python3 and psycopg2 to run it. And there is db connection string constant &quot;DB&quot; in the beginning of script you&#39;ll have to change.</div><div><br></div><div>Thank you for your work!</div><div>Sergey Melekhin</div></div></blockquote></div>