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:35 +0000 (10:22 +0900)
commit14a7b822530878069ab14dca99e0fb26fc6597ee
treeefcc249c6872e58078976c3aed483ad21c5f0b2e
parentba596715a862989867af4bbd136892352b2b39e1
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