<div dir="ltr">Hello,<div class="gmail_extra"><br><div class="gmail_quote">2014/1/8 Lachezar Dobrev <span dir="ltr"><<a href="mailto:l.dobrev@gmail.com" target="_blank">l.dobrev@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br> Did you try the 3.3.2 version without protocolVersion=2?<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yes, and I get same exception than previously.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This is something you should care about: when using a transaction<br>
all queries are sent to the master node. This is needed in order to<br>
preserve data integrity and isolation. If you want to use the slaves<br>
for read-only queries you must not do so in a transaction.<br>
For Springframwork I found out, that for read-only methods one<br>
should use @Transactional(propagation = Propagation.SUPPORTS, readOnly<br>
= true). This way Springframework creates the necessary infrastructure<br>
objects (Hibernate or JPA session) and will poll a connection to the<br>
database, but does not actually start a database transaction, which<br>
allows queries to go to a slave. This is a result of me talking to the<br>
Springframework guys a while back when we were trying Slony-I. I was<br>
advised to use this transactional demarcation to make use of read-only<br>
slaves.<br>
<br>
Please anyone feel free to correct me if you believe any of the<br>
above is wrong.<br>
<br>
Apparently when you use protocol version 2 the JDBC Driver uses a<br>
transaction (BEGIN; ... COMMIT) to execute the SET which *probably*<br>
makes it run on the master server only. I am not sure if this is a<br>
good thing. At best this seems to hide the problem, which might become<br>
apparent later.<br>
<br></blockquote><div><br></div><div>Thanks for these details. Tatsuo Ishii said that protocol version 2 does not support load balancing. So, I will have to give up it if I will must use this version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I currently have no test-bed with a running pgpool, but maybe you<br>
could create a simple test case: open a JDBC connection (no polling,<br>
no protocol specified, straight JDBC) to the pgpool, and observe the<br>
log files on both back-ends. Tatsuo Ishii noted, that the pgpool<br>
status shows that both back-ends behave differently when the SET is<br>
executed. There might be something there.<br>
</blockquote></div><br></div><div class="gmail_extra">The two servers are configured with the same parameters, except fot replication of course, and wal archiving, not activated on slave. Is it possible that the problem come from ?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Denis</div></div>