-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Docs] [YSQL] Added a limitation for READ COMMITTED isolation level #11646
Conversation
✔️ Deploy Preview for infallible-bardeen-164bc9 ready! 🔨 Explore the source changes: b051d0d 🔍 Inspect the deploy log: https://app.netlify.com/sites/infallible-bardeen-164bc9/deploys/622630b8d38b26000826281d 😎 Browse the preview: https://deploy-preview-11646--infallible-bardeen-164bc9.netlify.app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments
@@ -1204,6 +1200,15 @@ This feature interacts with the following features: | |||
1. **Follower reads (integration in progress):** When follower reads is turned on, the read point for each statement in a READ COMMITTED transaction will be picked as _Now()_ - _yb_follower_read_staleness_ms_ (if the transaction/statement is known to be explicitly/ implicitly read only). | |||
2. **Pessimistic locking:** READ COMMITTED has a dependency on pessimistic locking to fully work. To be precise, on facing a conflict, a transaction has to wait for the conflicting transaction to rollback/commit. Pessimistic locking behaviour can be seen for READ COMMITTED. An optimized version of pessimistic locking will come in near future, which will give better performance and will also work for REPEATABLE READ and SERIALIZABLE isolation levels. The optimized version will also help detect deadlocks proactively instead of relying on statement timeouts for deadlock avoidance (see example 1). | |||
|
|||
## Limitations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't number any headings, but if you do, number this one as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed numbering
@@ -1204,6 +1200,15 @@ This feature interacts with the following features: | |||
1. **Follower reads (integration in progress):** When follower reads is turned on, the read point for each statement in a READ COMMITTED transaction will be picked as _Now()_ - _yb_follower_read_staleness_ms_ (if the transaction/statement is known to be explicitly/ implicitly read only). | |||
2. **Pessimistic locking:** READ COMMITTED has a dependency on pessimistic locking to fully work. To be precise, on facing a conflict, a transaction has to wait for the conflicting transaction to rollback/commit. Pessimistic locking behaviour can be seen for READ COMMITTED. An optimized version of pessimistic locking will come in near future, which will give better performance and will also work for REPEATABLE READ and SERIALIZABLE isolation levels. The optimized version will also help detect deadlocks proactively instead of relying on statement timeouts for deadlock avoidance (see example 1). | |||
|
|||
## Limitations | |||
|
|||
1. READ COMMITTED semantics ensure that the client doesn't face conflict and read restart errors. YSQL maintains these semantics as long as a statement's output doesn't exceed ysql_output_buffer_size (a gflag with a default of 256KB). If this condition is not met, YSQL will resort to optimistic locking for that statement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put the gflag ysql_output_buffer_size inside ` characters, like ysql_pg_conf_csv is in section 6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
1. READ COMMITTED semantics ensure that the client doesn't face conflict and read restart errors. YSQL maintains these semantics as long as a statement's output doesn't exceed ysql_output_buffer_size (a gflag with a default of 256KB). If this condition is not met, YSQL will resort to optimistic locking for that statement. | ||
|
||
2. PostgreSQL requires the following as mentioned in its docs [here](https://www.postgresql.org/docs/current/xfunc-volatility.html) - _"STABLE and IMMUTABLE functions use a snapshot established as of the start of the calling query, whereas VOLATILE functions obtain a fresh snapshot at the start of each query they execute."_. YSQL uses a single snapshot for the whole procedure instead of one for each |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove extra period at end of first sentence, after the underline. There is a period in the quote, which finishes the sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
22c7a9d
to
a48b163
Compare
a48b163
to
b051d0d
Compare
No description provided.