[pgpool-hackers: 3164] Query hang issue with extended protocol

Muhammad Usama m.usama at gmail.com
Wed Dec 5 18:30:15 JST 2018


Hi Ishii San

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).

I think the problem is in pool_is_node_to_be_sent_in_current_query()
function. The issue is in streaming replication mode, when
pool_is_query_in_progress 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 pool_is_node_to_be_sent_in_current_query() the
VALID_BACKEND 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.


Can you please take a look at the attached patch, I am not sure if it will
have some side effects or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20181205/4311ce32/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valid_backend_fix.diff
Type: application/octet-stream
Size: 449 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20181205/4311ce32/attachment.obj>


More information about the pgpool-hackers mailing list