Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[#24898] YSQL: Change extended query protocol flow with Connection Ma…
…nager Summary: This patch changes the extended query protocol flow through connection manager to help facilitate correctness/consistency with batched mode of query execution. Problem: Connection Manager modifies extended query protocol-level communication between the client and server in order to support multiplexing of clients over a pool of server connections. This creates issues with the batched mode of execution owing to an incorrect order of packets being sent back to the client: - Connection Manager would always immediately send back a self-constructed ParseComplete packet to the client as soon as it received a Parse packet from the client - Connection Manager ignores ParseComplete packets sent by the server because it would conditionally send Parse packets from the client to the server The solution largely does the following: - Introduce a new flag `ysql_conn_mgr_optimized_extended_query_protocol` (bool val, default true) - if true, lessen correctness for scenarios where schema changes may be present between preparing statements, but increase performance - if false, extended query protocol will be supported with full correctness at the cost of performance - Note that either mode of execution ensures protocol-level communication correctness as well as consistency of batched mode of query execution. - Always send client-sent Parse packets to the server (this used to only happen if the server attached had not already parsed the **query** - the protocol-level name would be ignored) - Always forward server-sent ParseComplete packets back to the client (this used to always be ignored, Connection Manager would preemptively send back self-constructed ParseComplete packets to client) - Change the statement name being sent to the server to not only depend upon the query body, but also include dependency on: - logical client ID (only if `ysql_conn_mgr_optimized_extended_query_protocol` is false) - client-provided protocol level name The last change mentioned helps to deal with potential duplication issues as connection manager multiplexes multiple clients over multiple servers. Some more intricate details regarding this solution: - If we ever enter a scenario where Connection Manager routes the client to different servers between Parse and Bind phases, we will be forced to re-prepare the statement on the newer server selected - the Parse packets sent for these situations is a special packet specific to Connection Manager where we ask the server to not send back a ParseComplete packet to maintain protocol correctness between the client and server. (denoted by packet header 'p') - In "optimized" extended query protocol mode, it is possible for different logical connections to prepare the same query with the same statement name on a common server - we ask the server to perform a no-op instead of parsing the duplicate statement, and return a ParseComplete packet to maintain client-side protocol correctness. (denoted by packet header 'n') Misc fix included as a part of this diff: - Provide handling for Describe packet for unnamed prepared statements (mimics what is done for Bind phase for unnamed prepared statements, can refer to D41078 for additional details) Jira: DB-14026 Test Plan: Jenkins: enable connection manager, all tests Reviewers: skumar, devansh.saxena, stiwary, mkumar, vpatibandla, jason Reviewed By: devansh.saxena, mkumar, jason Subscribers: smishra, yql Differential Revision: https://phorge.dev.yugabyte.com/D41121
- Loading branch information