AWS Security ChangesHomeSearch

AWS aurora-dsql documentation change

Service: aurora-dsql · 2026-04-19 · Documentation low

File: aurora-dsql/latest/userguide/troubleshooting.md

Summary

Updated terminology from 'OCC errors' to 'concurrency control responses' and improved error message explanations for concurrency control scenarios

Security assessment

These changes improve documentation clarity around concurrency control mechanisms and error messages. While concurrency control relates to data integrity, these are documentation improvements rather than addressing specific security vulnerabilities. The changes provide better explanations of how catalog versioning and transaction conflicts work.

Diff

diff --git a/aurora-dsql/latest/userguide/troubleshooting.md b/aurora-dsql/latest/userguide/troubleshooting.md
index 779c8fdd1..f03c04a89 100644
--- a//aurora-dsql/latest/userguide/troubleshooting.md
+++ b//aurora-dsql/latest/userguide/troubleshooting.md
@@ -7 +7 @@
-Connection errorsAuthentication errorsAuthorization errorsSQL errorsOCC errorsSSL/TLS connections
+Connection errorsAuthentication errorsAuthorization errorsSQL errorsConcurrency control responsesSSL/TLS connections
@@ -25 +25 @@ The following topics provide troubleshooting advice for errors and issues that y
-  * Troubleshooting OCC errors
+  * Troubleshooting concurrency control responses
@@ -115 +115 @@ To create an index on a table with existing rows, you must use the `CREATE INDEX
-## Troubleshooting OCC errors
+## Troubleshooting concurrency control responses
@@ -119 +119 @@ To create an index on a table with existing rows, you must use the `CREATE INDEX
-This transaction attempted to modify the same tuples as another, concurrent, transaction. This indicates contention on the modified tuples. To learn more, please refer to [ Concurrency control in Aurora DSQL ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-concurrency-control.html)
+This transaction attempted to modify the same tuples as another concurrent transaction. This indicates contention on the modified tuples. To learn more, refer to [ Concurrency control in Aurora DSQL ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-concurrency-control.html).
@@ -121 +121 @@ This transaction attempted to modify the same tuples as another, concurrent, tra
-**OC001 “ERROR: schema has been updated by another transaction, retry as needed”**
+**OC001 “ERROR: schema has been updated by another transaction, please retry: (OC001)”**
@@ -123 +123 @@ This transaction attempted to modify the same tuples as another, concurrent, tra
-Your PostgreSQL session had a cached copy of the schema catalog. That cached copy was valid at the time was loaded. Let’s call the time T1 and the version V1.
+Your session had a cached copy of the schema catalog at version V1, loaded at time T1.
@@ -125 +125 @@ Your PostgreSQL session had a cached copy of the schema catalog. That cached cop
-Another transaction updates the catalog at time T2. Let’s call this V2.
+A separate transaction updated the catalog to version V2 at time T2.
@@ -127 +127 @@ Another transaction updates the catalog at time T2. Let’s call this V2.
-When the original session attempts to read from storage at time T2 it’s still using catalog version V1. Aurora DSQL’s storage layer rejects the request because the latest catalog version at T2 is V2.
+At time T3, when your session runs a query, it detects that it's behind and attempts to rebase onto the new catalog changes. In some situations the rebase can't succeed, and Aurora DSQL returns a `40001` OC001 response. The time between T2 and T3 can range from milliseconds to minutes, because query processors discover catalog changes reactively rather than receiving proactive updates.
@@ -129 +129 @@ When the original session attempts to read from storage at time T2 it’s still
-When you retry at time T3 from the original session, Aurora DSQL refreshes the catalog cache. The transaction at T3 is using catalog V2. Aurora DSQL will finish the transaction as long as no other catalog changes came through since time T2.
+When you retry from the same session, Aurora DSQL refreshes the catalog cache. The retried transaction uses catalog V2 and succeeds as long as no further catalog changes have occurred since T2.