This is an automated email from the ASF dual-hosted git repository.
vldpyatkov pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ignite.git
The following commit(s) were added to refs/heads/master by this push:
new fd959e7c36c IGNITE-28981 Document Calcite SELECT FOR UPDATE (#13475)
fd959e7c36c is described below
commit fd959e7c36c1e92101632351f3549580c0b9084a
Author: ignitetcbot <[email protected]>
AuthorDate: Thu Aug 20 12:12:09 2026 +0300
IGNITE-28981 Document Calcite SELECT FOR UPDATE (#13475)
---
docs/_docs/SQL/sql-calcite.adoc | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/docs/_docs/SQL/sql-calcite.adoc b/docs/_docs/SQL/sql-calcite.adoc
index d60a732cd66..bc7136233bb 100644
--- a/docs/_docs/SQL/sql-calcite.adoc
+++ b/docs/_docs/SQL/sql-calcite.adoc
@@ -1270,10 +1270,23 @@ So, when `txAwareQueriesEnabled = true` enabled the
usage:
====
[discrete]
=== SELECT ... FOR UPDATE
-Currently, no locks are held by the UPDATE or SELECT statements.
-`SELECT ... FOR UPDATE` statement not supported.
-This means lost updates can occur when multiple transactions concurrently
modify the same key.
+The Calcite-based query engine supports `SELECT ... FOR UPDATE` inside a
`PESSIMISTIC` transaction.
+The statement acquires row-level locks for the cache entries returned by the
query and returns the selected rows.
-For example, if you execute a query like `SET salary = salary + 50 WHERE id =
1` concurrently across multiple threads,
-note that due to the lost-update anomaly, the final value may not equal the
original salary plus 50 multiplied by the number of threads.
+[source,sql]
+----
+SELECT id, salary FROM Person WHERE id = 1 FOR UPDATE;
+SELECT p.id FROM Person p JOIN Dept d ON p.deptId = d.id FOR UPDATE OF p.id;
+SELECT id FROM Person WHERE id = 1 FOR UPDATE NOWAIT;
+SELECT id FROM Person WHERE id = 1 FOR UPDATE WAIT 5;
+----
+
+Without `OF`, rows from all cache-based tables participating in the query are
locked.
+With `OF`, only rows from the tables that own the listed columns are locked.
+`NOWAIT` fails immediately if a required lock cannot be acquired.
+`WAIT n` waits up to `n` seconds.
+If neither option is specified, Ignite uses the transaction timeout.
+
+`SELECT ... FOR UPDATE` is supported only for plain `SELECT` queries over
cache-based tables and joins of such tables.
+It is not supported for `DISTINCT`, `GROUP BY`, `HAVING`, aggregate-only
result sets, system views, or table functions.
====
