-
Notifications
You must be signed in to change notification settings - Fork 419
Cockroachdb connection pooling #87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
UPDATE: Cockroach doesn't support plpgsql. Is there a way to use asyncpg's connection pooling without plpgsql scripts? |
We could put a check there if cocroach distinguishes itself somehow through its version string. What does |
|
That seems like a stock Postgres response. We need some way to tell that it's not Postgres on the other end. |
I couldn't find suitable statement: https://www.cockroachlabs.com/docs/sql-statements.html How about explicitly telling to the pool with a parameter? |
Also perhaps cockroachdb/cockroach#14142 would help? (once solved) |
I don't think it's a good idea. |
Yes, anything on SQL level that does not raise an error under Postgres would be fine. |
@knz Ideally, though, Cocroach should send something in the |
@elprans do you reckon (other) clients would be confused by receiving a parameterstatus key that's not provided by pg otherwise? |
@knz I doubt that. Postgres itself adds new keys periodically: https://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-ASYNC |
Relevant excerpt:
|
…ssage. Discussed in MagicStack/asyncpg#87 (comment) It is useful for clients to know that they are actually talking to a CockroachDB SQL node, as opposed to a real PostgreSQL server. At this point there is no way to determine a client is connected to CockroachDB using a SQL statement/query that would not otherwise *fail* in PostgreSQL. This patch addresses this limitation by returning a new `crdb_version` parameter in the ParameterStatus message. (https://www.postgresql.org/docs/9.5/static/protocol-message-formats.html) This is safe because as explained in https://www.postgresql.org/docs/9.5/static/protocol-flow.html#PROTOCOL-ASYNC "This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about."
…ssage. Discussed in MagicStack/asyncpg#87 (comment) It is useful for clients to know that they are actually talking to a CockroachDB SQL node, as opposed to a real PostgreSQL server. At this point there is no way to determine a client is connected to CockroachDB using a SQL statement/query that would not otherwise *fail* in PostgreSQL. This patch addresses this limitation by returning a new `crdb_version` parameter in the ParameterStatus message. (https://www.postgresql.org/docs/9.5/static/protocol-message-formats.html) This is safe because as explained in https://www.postgresql.org/docs/9.5/static/protocol-flow.html#PROTOCOL-ASYNC "This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about."
…ssage. Discussed in MagicStack/asyncpg#87 (comment) It is useful for clients to know that they are actually talking to a CockroachDB SQL node, as opposed to a real PostgreSQL server. At this point there is no way to determine a client is connected to CockroachDB using a SQL statement/query that would not otherwise *fail* in PostgreSQL. This patch addresses this limitation by returning a new `crdb_version` parameter in the ParameterStatus message. (https://www.postgresql.org/docs/9.5/static/protocol-message-formats.html) This is safe because as explained in https://www.postgresql.org/docs/9.5/static/protocol-flow.html#PROTOCOL-ASYNC "This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about."
Great! 👍 Really appreciate your work! |
The ParameterStatus is |
@elprans I've built a docker image kszucs/cockroach:20170314 |
Add basic server capability detection mechanism based on server version and parameters reported by the server through ParameterStatus messages. This allows altering certain asyncpg behaviour based on the connected server. Specifically, this allows asyncpg to connect to CochroachDB servers. Fixes #87.
Add basic server capability detection mechanism based on server version and parameters reported by the server through ParameterStatus messages. This allows altering certain asyncpg behaviour based on the connected server. Specifically, this allows asyncpg to connect to CochroachDB servers. Fixes #87.
Add basic server capability detection mechanism based on server version and parameters reported by the server through ParameterStatus messages. This allows altering certain asyncpg behaviour based on the connected server. Specifically, this allows asyncpg to connect to CochroachDB servers. Fixes #87.
Add basic server capability detection mechanism based on server version and parameters reported by the server through ParameterStatus messages. This allows altering certain asyncpg behaviour based on the connected server. Specifically, this allows asyncpg to connect to CochroachDB servers. Fixes #87.
Add basic server capability detection mechanism based on server version and parameters reported by the server through ParameterStatus messages. This allows altering certain asyncpg behaviour based on the connected server. Specifically, this allows asyncpg to connect to CochroachDB servers. Fixes #87.
Great, thanks! |
For clients it may be useful to know that they're communicating with CrateDB instead of a PostgreSQL instance. For example to adapt the server capabilities. One such client is asyncpg, see MagicStack/asyncpg#87
For clients it may be useful to know that they're communicating with CrateDB instead of a PostgreSQL instance. For example to adapt the server capabilities. One such client is asyncpg, see MagicStack/asyncpg#87
For clients it may be useful to know that they're communicating with CrateDB instead of a PostgreSQL instance. For example to adapt the server capabilities. One such client is asyncpg, see MagicStack/asyncpg#87
…ssage. Discussed in MagicStack/asyncpg#87 (comment) It is useful for clients to know that they are actually talking to a CockroachDB SQL node, as opposed to a real PostgreSQL server. At this point there is no way to determine a client is connected to CockroachDB using a SQL statement/query that would not otherwise *fail* in PostgreSQL. This patch addresses this limitation by returning a new `crdb_version` parameter in the ParameterStatus message. (https://www.postgresql.org/docs/9.5/static/protocol-message-formats.html) This is safe because as explained in https://www.postgresql.org/docs/9.5/static/protocol-flow.html#PROTOCOL-ASYNC "This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about."
uvloop?: not related
I'm trying to use cockroachdb with asyncpg.
With plain connection it works like a charm. On the other hand using connection pool fails with the following error:
Caused by the resetting the connection :
I don't know the exact solution, but I'd like to use Cockroach with asyncpg :)
I've created an issue for cockroach developers too cockroachdb/examples-orms#19
The text was updated successfully, but these errors were encountered: