<div dir="ltr">Hi Ishii San<br><br>I was investigating the issue faced by one of Pgpool-II user who reported that after executing a certain transaction (large amount of data DELETE / INSERT / UPDATE, COMMIT), the next execution of the BEGIN statement hangs(using the extended query protocol). <div><br>I think the problem is in <font face="monospace, monospace">pool_is_node_to_be_sent_in_current_query</font>() function. The issue is in streaming replication mode, when  <font face="monospace, monospace">pool_is_query_in_progress</font> is not set, the function always returns true. Now consider that we have two backend servers 1 primary and one standby. And for a particular session the primary node gets selected as a load balance node. So effectively that session should only be sending queries and reading responses from primary server alone. But with the current implementation of <font face="monospace, monospace">pool_is_node_to_be_sent_in_current_query</font>() the <font face="monospace, monospace">VALID_BACKEND</font> macro will return true for standby node as well when the query in progress flag is not set(which is wrong when standby node is not selected for load balancing). and if this happens in let say read_kind_from_backend() function we will get a stuck, since the read_kind_from_backend() will be trying to read the response from standby node while we have never sent any query to that node.<br><br><br>Can you please take a look at the attached patch, I am not sure if it will have some side effects or not.<br><br><br> 

















</div></div>