<div dir="ltr"><div class="gmail_quote">On Fri, Oct 26, 2012 at 6:00 AM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry for late reply.<br>
<div class="im"><br>
> Hi,<br>
><br>
> The docs [1] say that one of the preconditions for load-balancing is<br>
> that<br>
><br>
> > The query must not be in an explicitly declared transaction (i.e. not<br>
> in a BEGIN ~ END block)<br>
<br>
</div>Yeah, the doc is outdated in this regard.<br>
<div class="im"><br>
> But I see that this is not a strict statement. I extracted a specific<br>
> backend process' log lines (generated using log_per_node_statement), and I<br>
> could see that on line 6, the SELECT query was load-balanced to a replica<br>
> (node id 2) and the next INSERT statement was correctly sent to the master.<br>
> But any SELECT after that INSERT was not sent to the replica, and only to<br>
> the master.<br>
><br>
> So can we say that load balancing _does_ occur in an explicitly<br>
> declared transaction, but as soon as a DML operation is perfored, any<br>
> subsequent SELECT queries will be sent only to master.<br>
<br>
</div>Yes, that is expected behavior if you are using streaming replication<br>
mode. The reason why SELECTs are sent to master after DML issued is,<br>
standby cannot see the modified rows.<br clear="all"></blockquote><div><br>Can we expect doc changes, or I should probably file a bug-report against documentation so that it gets taken care of in due process.<br></div></div>
<br>Best regards,<br>-- <br><div dir="ltr">Gurjeet Singh<br><br><a href="http://gurjeet.singh.im/" target="_blank">http://gurjeet.singh.im/</a><br></div><br>
</div>