AWS aurora-dsql documentation change
Summary
Updated documentation about DDL behavior differences in Aurora DSQL, including concurrency control errors, transaction restrictions, and asynchronous DDL implementation details. Added structured sections with clearer examples and comparisons to PostgreSQL.
Security assessment
The changes focus on explaining concurrency control mechanisms and transaction limitations rather than addressing security vulnerabilities or describing security features. The error [40001] mentioned relates to transaction concurrency issues, not security flaws. No evidence of CVE fixes, vulnerability disclosures, or security enhancements.
Diff
diff --git a/aurora-dsql/latest/userguide/working-with-ddl.md b/aurora-dsql/latest/userguide/working-with-ddl.md index 82edf8074..dd992945e 100644 --- a//aurora-dsql/latest/userguide/working-with-ddl.md +++ b//aurora-dsql/latest/userguide/working-with-ddl.md @@ -7 +7 @@ Amazon Aurora DSQL is provided as a Preview service. To learn more, see [Betas a -# Understanding data definition language (DDL) in Aurora DSQL +# DDL and distributed transactions in Aurora DSQL @@ -9 +9 @@ Amazon Aurora DSQL is provided as a Preview service. To learn more, see [Betas a -Aurora DSQL features a Multi-AZ distributed and shared-nothing database layer built on top of multi-tenant compute and storage fleets. Because there isn't a single primary database node or leader, the database catalog is distributed, and schema changes are managed as distributed transactions. As such, there are a few ways in which DDL behaves differently in Aurora DSQL than PostgreSQL. +Data definition language (DDL) behaves differently in Aurora DSQL from PostgreSQL. Aurora DSQL features a Multi-AZ distributed and shared-nothing database layer built on top of multi-tenant compute and storage fleets. Because no single primary database node or leader exists, the database catalog is distributed. Thus, Aurora DSQL manages DDL schema changes as distributed transactions. @@ -11 +11 @@ Aurora DSQL features a Multi-AZ distributed and shared-nothing database layer bu - * Aurora DSQL throws a concurrency control violation error if you run one transaction while another transaction updates a resource. Consider the following example. +Specifically, DDL behaves differently in Aurora DSQL as follows: @@ -13 +13 @@ Aurora DSQL features a Multi-AZ distributed and shared-nothing database layer bu - * Create table `foobar` in session 1. +**Concurrency control errors** @@ -15 +15,8 @@ Aurora DSQL features a Multi-AZ distributed and shared-nothing database layer bu - * After Aurora DSQL creates the table `foobar`, you run the statement `SELECT * from foobar` in session 2. Aurora DSQL returns with the error `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).` + +Aurora DSQL returns a concurrency control violation error if you run one transaction while another transaction updates a resource. For example, consider the following sequence of actions: + + 1. In session 1, a user creates the table `mytable`. + + 2. In session 2, a user runs the statement `SELECT * from mytable`. + +Aurora DSQL returns the error `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).` @@ -21 +27,0 @@ During preview, there is a known issue that increases the scope of this concurre - * Transactions in Aurora DSQL can contain only one DDL statement and can't have both DDL and DML statements. For example, you can't create a table and insert data into the same table within the same transaction. @@ -23 +29,7 @@ During preview, there is a known issue that increases the scope of this concurre -For example, Aurora DSQL supports the following statements. + + +**DDL and DML in the same transaction** + + +Transactions in Aurora DSQL can contain only one DDL statement and can't have both DDL and DML statements. This restriction means that you can't create a table and insert data into the same table within the same transaction. For example, Aurora DSQL supports the following sequential transactions. + @@ -26 +38 @@ For example, Aurora DSQL supports the following statements. - CREATE TABLE FOO (ID_col integer); + CREATE TABLE mytable (ID_col integer); @@ -33 +45,2 @@ For example, Aurora DSQL supports the following statements. -Aurora DSQL doesn't support the following. +Aurora DSQL doesn't support the following transaction, which includes both `CREATE` and `INSERT` statements. + @@ -40,2 +53 @@ Aurora DSQL doesn't support the following. - * Finally, Aurora DSQL runs DDL statements asynchronously. This means that changes to large tables, such as adding an index or modifying a column, can run without downtime or performance impact. For more information about Aurora DSQL's asynchronous job manager, see [Creating async indexes in Aurora DSQL](./working-with-create-index-async.html). - +**Asynchronous DDL** @@ -43,0 +56 @@ Aurora DSQL doesn't support the following. +In standard PostgreSQL, DDL operations such as `CREATE INDEX` lock the affected table, making it unavailable for reads and writes from other sessions. In Aurora DSQL, these DDL statements run asynchronously using a background manager. Access to the affected table isn't blocked. Thus, DDL on large tables can run without downtime or performance impact. For more information about the asynchronous job manager in Aurora DSQL, see [Asynchronous indexes in Aurora DSQL](./working-with-create-index-async.html).