Fix occasional query hang while processing DEALLOCATE.
authorTatsuo Ishii <ishii@sraoss.co.jp>
Mon, 16 Sep 2019 00:24:08 +0000 (09:24 +0900)
committerTatsuo Ishii <ishii@sraoss.co.jp>
Mon, 16 Sep 2019 01:22:06 +0000 (10:22 +0900)
commit8925e047fb42ae758966efa8eade47f6f8fbc41c
tree740433f77266f7805b81f6e8e662495786ebc848
parent1e6fae7ae8319e7ba170f7d524c67a916daf780d
Fix occasional query hang while processing DEALLOCATE.

When DEALLOCATE tries to remove a named statement, it inherits
where_to_send map of the named statement in
where_to_send_deallocate(). However it forgot to copy the load balance
node id in the query context of the named statement. This made sending
query to backend not happen: if the target node id is different from
query_context->load_balance_node_id nor primary node id,
pool_virtual_master_db_node_id (it is called as MASTER_NODE_ID)
returns primary node id, and pool_send_and_wait(MASTER_NODE_ID)
ignores the request because VALID_BACKEND returns false in this case
(MASTER_NODE_ID = primary node id is not in the where_to_send map). As
a result, following check_error() waits for response from backend in
vain.

Fix is, let where_to_send_deallocate() copy load balance node id from
the query context of the previous named statement.

Per bug 546.
src/context/pool_query_context.c