Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
database/sql: prepare command is always sent again when executing a statement on a DB pool with multiple open connections #32298
What did you do?
Executing a prepared sql query on a DB connection pool with at least 2 open connections always sends the
For reproducing the error, first enable general logging in your MySQL DB:
Now, connect to your mysql DB:
Then run some concurrent sql commands to make sure the pool has more than one open connection:
Now that we have at least two open connections, run a prepare and execute command on the DB:
What did you expect to see?
What did you see instead?
After investigation, we found that the
We tested this hypothesis by implementing a function that iterated over
Yes, we are going to switch to a dedicated connection for our use case. However, we still think this behaviour should be fixed without having to use one since Prepare() can be run on the DB pool.…
________________________________ From: Daniel Theophanes <email@example.com> Sent: Thursday, May 30, 2019 2:31:57 AM To: golang/go Cc: Nishaad Ajani; Mention Subject: Re: [golang/go] database/sql: prepare command is always sent again when executing a statement on a DB pool with multiple open connections (#32298) @nishaad78<https://github.com/nishaad78> I can review the CL for your for Go1.14 (we are still in a freeze for 1.13). For your use case, have you considered using a dedicated Conn() and calling prepare and execute on a single Conn? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#32298?email_source=notifications&email_token=AB7ZYNLVOXQTWMVKIXYSYTTPX3DZ3A5CNFSM4HQI6NUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQHQ2Q#issuecomment-497055850>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB7ZYNIYC6ADB3BHBAOSUWTPX3DZ3ANCNFSM4HQI6NUA>.
@nishaad78 I'm glad you choose to move to a dedicated connection.
Of the entire sql package code base, I find the statement sub-pools the most challenging. Your CL may be fine, but I highly doubt I will be able to merge or maintain it.
EDIT: To be clear, unless a simpler, very straightforward solution is presented, this will likely be declined.