[doc] Added sticky connections section to Connection Manager docs #26114
+24
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for infallible-bardeen-164bc9 ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
ddhodge
reviewed
Feb 21, 2025
| YSQL Connection Manager enables a larger number of client connections to efficiently share a smaller pool of backend processes using a many-to-one multiplexing model. However, in certain cases, a backend process may enter a state that prevents connection multiplexing between transactions. When this occurs, the backend process remains dedicated to a single logical connection (hence the term “sticky connection”) for the entire session rather than just a single transaction. This behavior deviates from the typical use case, where backend processes are reassigned after each transaction. | ||
|
|
||
| Some other characteristics of sticky connections: | ||
| - Backend processes corresponding to sticky connections are destroyed at the end of the session, and so, sticky connections do not return to the pool once used. |
There was a problem hiding this comment.
I don't understand how the one relates to the other, or what you are saying here. Why don't sticky connections return to pool? Even after related backend process is destroyed at end of session?
|
|
||
| Some other characteristics of sticky connections: | ||
| - Backend processes corresponding to sticky connections are destroyed at the end of the session, and so, sticky connections do not return to the pool once used. | ||
| - As of now, sticky connections cannot be reverted back to an "un"-sticky connection; once a sticky connection is formed, it will remain sticky until the end of the session. |
There was a problem hiding this comment.
This implies the opposite - it will return to pool at end of session
| @@ -105,6 +105,30 @@ The following table describes YB-TServer flags related to YSQL Connection Manage | |||
| | ysql_conn_mgr_sequence_support_mode | Sequence support mode when YSQL connection manager is enabled. When set to 'pooled_without_curval_lastval', the currval() and lastval() functions are not supported. When set to 'pooled_with_curval_lastval', the currval() and lastval() functions are supported. For both settings, monotonic sequence order is not guaranteed if `ysql_sequence_cache_method` is set to `connection`. To also support monotonic order, set this flag to `session`. | pooled_without_curval_lastval | | |||
| | ysql_conn_mgr_optimized_extended_query_protocol | Enables optimization of [extended-query protocol](https://www.postgresql.org/docs/current/protocol-overview.html#PROTOCOL-QUERY-CONCEPTS) to provide better performance; note that while optimization is enabled, you may have correctness issues if you alter the schema of objects used in prepared statements. If set to false, extended-query protocol handling is always fully correct but unoptimized. | true | | |||
|
|
|||
| ## Sticky Connections | |||
There was a problem hiding this comment.
Suggested change
| ## Sticky Connections | |
| ## Sticky connections |
| - Backend processes corresponding to sticky connections are destroyed at the end of the session, and so, sticky connections do not return to the pool once used. | ||
| - As of now, sticky connections cannot be reverted back to an "un"-sticky connection; once a sticky connection is formed, it will remain sticky until the end of the session. | ||
|
|
||
| This section outlines the various scenarios where the user can expect a logical connection to be converted into a sticky connection while using YSQL Connection Manager. |
There was a problem hiding this comment.
Suggested change
| This section outlines the various scenarios where the user can expect a logical connection to be converted into a sticky connection while using YSQL Connection Manager. | |
| When using YSQL Connection Manager, sticky connections can form in the following circumstances: |
| - Creation of `TEMP` tables | ||
| - Declaration of a `CURSOR` using the `WITH HOLD` attribute | ||
| - Using a `PREPARE` query (Not to be confused with protocol-level preparation of statements) | ||
| - Superuser connections (This can be disabled using the `ysql_conn_mgr_superuser_sticky` flag) |
There was a problem hiding this comment.
'This' - what is disabled? superuser connections?
| - Using a `PREPARE` query (Not to be confused with protocol-level preparation of statements) | ||
| - Superuser connections (This can be disabled using the `ysql_conn_mgr_superuser_sticky` flag) | ||
| - Using a `SEQUENCE` can make the connection sticky (Refer to `ysql_conn_mgr_sequence_support_mode` for support without stickiness) | ||
| - Replication connections |
There was a problem hiding this comment.
CDC? xCluster? Any replication?
| - Superuser connections (This can be disabled using the `ysql_conn_mgr_superuser_sticky` flag) | ||
| - Using a `SEQUENCE` can make the connection sticky (Refer to `ysql_conn_mgr_sequence_support_mode` for support without stickiness) | ||
| - Replication connections | ||
| - Usage of specific session parameters (GUC variables) during the session: |
There was a problem hiding this comment.
Suggested change
| - Usage of specific session parameters (GUC variables) during the session: | |
| - Setting the following configuration parameters during the session: |
|
|
||
| This section outlines the various scenarios where the user can expect a logical connection to be converted into a sticky connection while using YSQL Connection Manager. | ||
|
|
||
| - Creation of `TEMP` tables |
There was a problem hiding this comment.
Suggested change
| - Creation of `TEMP` tables | |
| - Creating TEMP tables |
| This section outlines the various scenarios where the user can expect a logical connection to be converted into a sticky connection while using YSQL Connection Manager. | ||
|
|
||
| - Creation of `TEMP` tables | ||
| - Declaration of a `CURSOR` using the `WITH HOLD` attribute |
There was a problem hiding this comment.
Suggested change
| - Declaration of a `CURSOR` using the `WITH HOLD` attribute | |
| - Declaring a CURSOR using the WITH HOLD attribute |
|
|
||
| - Creation of `TEMP` tables | ||
| - Declaration of a `CURSOR` using the `WITH HOLD` attribute | ||
| - Using a `PREPARE` query (Not to be confused with protocol-level preparation of statements) |
There was a problem hiding this comment.
Suggested change
| - Using a `PREPARE` query (Not to be confused with protocol-level preparation of statements) | |
| - Using a PREPARE query (not to be confused with protocol-level preparation of statements) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.