Queries simply see the latest committed version, or snapshot, of the data, rather than waiting for the next version to be committed.
Amazon Redshift supports a default automatic commit behavior in which each separately-executed
SQL command commits individually. If you enclose a set of commands in a transaction block
(defined by BEGIN and END statements), the block commits as one transaction,
so you can roll it back if necessary. An exception to this behavior is the TRUNCATE command,
which automatically commits all outstanding changes made in the current transaction without
requiring an END statement.
System catalog tables (PG) and other Amazon Redshift system tables (STL and STV) are not locked in a transaction
UPDATEs and DELETEs have to read a snapshot of the data from the last commit. When the first UPDATE or DELETE releases its lock, the second UPDATE or DELETE needs to determine whether the data that it is going to work with is potentially stale. It will not be stale , because the second transaction does not obtain its snapshot of data until after the first transaction has released its lock.
Whenever transactions involve updates of more than one table, there is always the possibility of
concurrently-running transactions becoming deadlocked when they both try to write to the same set of tables. A transaction releases all of its table locks at once when it either commits or rolls back; it does not relinquish locks one at a time.
COPY and INSERT operations against the same table are held in a wait state until the lock is released, then they proceed as normal.
Amazon Redshift supports a default automatic commit behavior in which each separately-executed
SQL command commits individually. If you enclose a set of commands in a transaction block
(defined by BEGIN and END statements), the block commits as one transaction,
so you can roll it back if necessary. An exception to this behavior is the TRUNCATE command,
which automatically commits all outstanding changes made in the current transaction without
requiring an END statement.
System catalog tables (PG) and other Amazon Redshift system tables (STL and STV) are not locked in a transaction
UPDATEs and DELETEs have to read a snapshot of the data from the last commit. When the first UPDATE or DELETE releases its lock, the second UPDATE or DELETE needs to determine whether the data that it is going to work with is potentially stale. It will not be stale , because the second transaction does not obtain its snapshot of data until after the first transaction has released its lock.
Whenever transactions involve updates of more than one table, there is always the possibility of
concurrently-running transactions becoming deadlocked when they both try to write to the same set of tables. A transaction releases all of its table locks at once when it either commits or rolls back; it does not relinquish locks one at a time.
COPY and INSERT operations against the same table are held in a wait state until the lock is released, then they proceed as normal.
Comments