Merge branch '3.0' into feature/3.0_interval_hash_optimize

docs/en/12-taos-sql/06-select.md

@@ -348,19 +348,15 @@ SELECT ... FROM (SELECT ... FROM ...) ...;
 
 :::info
 
-- Only one layer of nesting is allowed, that means no sub query is allowed within a sub query
-- The result set returned by the inner query will be used as a "virtual table" by the outer query. The "virtual table" can be renamed using `AS` keyword for easy reference in the outer query.
-- Sub query is not allowed in continuous query.
+- The result of a nested query is returned as a virtual table used by the outer query. It's recommended to give an alias to this table for the convenience of using it in the outer query.
 - JOIN operation is allowed between tables/STables inside both inner and outer queries. Join operation can be performed on the result set of the inner query.
-- UNION operation is not allowed in either inner query or outer query.
-- The functions that can be used in the inner query are the same as those that can be used in a non-nested query.
+- The features that can be used in the inner query are the same as those that can be used in a non-nested query.
   - `ORDER BY` inside the inner query is unnecessary and will slow down the query performance significantly. It is best to avoid the use of `ORDER BY` inside the inner query.
 - Compared to the non-nested query, the functionality that can be used in the outer query has the following restrictions:
   - Functions
-    - If the result set returned by the inner query doesn't contain timestamp column, then functions relying on timestamp can't be used in the outer query, like `TOP`, `BOTTOM`, `FIRST`, `LAST`, `DIFF`.
-    - Functions that need to scan the data twice can't be used in the outer query, like `STDDEV`, `PERCENTILE`.
-  - `IN` operator is not allowed in the outer query but can be used in the inner query.
-  - `GROUP BY` is not supported in the outer query.
+    - If the result set returned by the inner query doesn't contain timestamp column, then functions relying on timestamp can't be used in the outer query, like INTERP,DERIVATIVE, IRATE, LAST_ROW, FIRST, LAST, TWA, STATEDURATION, TAIL, UNIQUE.
+    - If the result set returned by the inner query are not sorted in order by timestamp, then functions relying on data ordered by timestamp can't be used in the outer query, like LEASTSQUARES, ELAPSED, INTERP, DERIVATIVE, IRATE, TWA, DIFF, STATECOUNT, STATEDURATION, CSUM, MAVG, TAIL, UNIQUE. 
+    - Functions that need to scan the data twice can't be used in the outer query, like PERCENTILE.
 
 :::
 

docs/en/12-taos-sql/12-distinguished.md

@@ -5,11 +5,11 @@ title: Time-Series Extensions
 
 As a purpose-built database for storing and processing time-series data, TDengine provides time-series-specific extensions to standard SQL.
 
-These extensions include tag-partitioned queries and windowed queries.
+These extensions include partitioned queries and windowed queries.
 
-## Tag-Partitioned Queries
+## Partitioned Queries
 
-When you query a supertable, you may need to partition the supertable by tag and perform additional operations on a specific partition. In this case, you can use the following SQL clause:
+When you query a supertable, you may need to partition the supertable by some dimensions and perform additional operations on a specific partition. In this case, you can use the following SQL clause:
 
 ```sql
 PARTITION BY part_list
@@ -17,22 +17,24 @@ PARTITION BY part_list
 
 part_list can be any scalar expression, such as a column, constant, scalar function, or a combination of the preceding items.
 
-A PARTITION BY clause with a tag is processed as follows:
+A PARTITION BY clause is processed as follows:
 
-- The PARTITION BY clause must occur after the WHERE clause and cannot be used with a JOIN clause.
-- The PARTITION BY clause partitions the super table by the specified tag group, and the specified calculation is performed on each partition. The calculation performed is determined by the rest of the statement - a window clause, GROUP BY clause, or SELECT clause.
-- You can use PARTITION BY together with a window clause or GROUP BY clause. In this case, the window or GROUP BY clause takes effect on every partition. For example, the following statement partitions the table by the location tag, performs downsampling over a 10 minute window, and returns the maximum value:
+- The PARTITION BY clause must occur after the WHERE clause
+- The PARTITION BY caluse partitions the data according to the specified dimentions, then perform computation on each partition. The performed computation is determined by the rest of the statement - a window clause, GROUP BY clause, or SELECT clause.
+- The PARTITION BY clause can be used together with a window clause or GROUP BY clause. In this case, the window or GROUP BY clause takes effect on every partition. For example, the following statement partitions the table by the location tag, performs downsampling over a 10 minute window, and returns the maximum value:
 
 ```sql
 select max(current) from meters partition by location interval(10m)
 ```
 
+The most common usage of PARTITION BY is partitioning the data in subtables by tags then perform computation when querying data in a supertable. More specifically, `PARTITION BY TBNAME` partitions the data of each subtable into a single timeline, and this method facilitates the statistical analysis in many use cases of processing timeseries data.
+
 ## Windowed Queries
 
 Aggregation by time window is supported in TDengine. For example, in the case where temperature sensors report the temperature every seconds, the average temperature for every 10 minutes can be retrieved by performing a query with a time window. Window related clauses are used to divide the data set to be queried into subsets and then aggregation is performed across the subsets. There are three kinds of windows: time window, status window, and session window. There are two kinds of time windows: sliding window and flip time/tumbling window. The query syntax is as follows:
 
 ```sql
-SELECT function_list FROM tb_name
+SELECT select_list FROM tb_name
   [WHERE where_condition]
   [SESSION(ts_col, tol_val)]
   [STATE_WINDOW(col)]
@@ -42,12 +44,6 @@ SELECT function_list FROM tb_name
 
 The following restrictions apply:
 
-### Restricted Functions
-
-- Aggregate functions and select functions can be used in `function_list`, with each function having only one output. For example COUNT, AVG, SUM, STDDEV, LEASTSQUARES, PERCENTILE, MIN, MAX, FIRST, LAST. Functions having multiple outputs, such as DIFF or arithmetic operations can't be used.
-- `LAST_ROW` can't be used together with window aggregate.
-- Scalar functions, like CEIL/FLOOR, can't be used with window aggregate.
-
 ### Other Rules
 
 - The window clause must occur after the PARTITION BY clause and before the GROUP BY clause. It cannot be used with a GROUP BY clause.
@@ -82,7 +78,7 @@ These pseudocolumns occur after the aggregation clause.
 
 1. A huge volume of interpolation output may be returned using `FILL`, so it's recommended to specify the time range when using `FILL`. The maximum number of interpolation values that can be returned in a single query is 10,000,000.
 2. The result set is in ascending order of timestamp when you aggregate by time window.
-3. If aggregate by window is used on STable, the aggregate function is performed on all the rows matching the filter conditions. If `GROUP BY` is not used in the query, the result set will be returned in ascending order of timestamp; otherwise the result set is not exactly in the order of ascending timestamp in each group.
+3. If aggregate by window is used on STable, the aggregate function is performed on all the rows matching the filter conditions. If `PARTITION BY` is not used in the query, the result set will be returned in strict ascending order of timestamp; otherwise the result set is not exactly in the order of ascending timestamp in each group.
 
 :::
 
@@ -112,9 +108,9 @@ When using time windows, note the following:
 Please note that the `timezone` parameter should be configured to be the same value in the `taos.cfg` configuration file on client side and server side.
 - The result set is in ascending order of timestamp when you aggregate by time window.
 
-### Status Window
+### State Window
 
-In case of using integer, bool, or string to represent the status of a device at any given moment, continuous rows with the same status belong to a status window. Once the status changes, the status window closes. As shown in the following figure, there are two status windows according to status, [2019-04-28 14:22:07，2019-04-28 14:22:10] and [2019-04-28 14:22:11，2019-04-28 14:22:12]. Status window is not applicable to STable for now.
+In case of using integer, bool, or string to represent the status of a device at any given moment, continuous rows with the same status belong to a status window. Once the status changes, the status window closes. As shown in the following figure, there are two state windows according to status, [2019-04-28 14:22:07，2019-04-28 14:22:10] and [2019-04-28 14:22:11，2019-04-28 14:22:12]. 
 
 ![TDengine Database Status Window](./timewindow-3.webp)
 
@@ -130,7 +126,7 @@ The primary key, i.e. timestamp, is used to determine which session window a row
 
 ![TDengine Database Session Window](./timewindow-2.webp)
 
-If the time interval between two continuous rows are within the time interval specified by `tol_value` they belong to the same session window; otherwise a new session window is started automatically. Session window is not supported on STable for now.
+If the time interval between two continuous rows are within the time interval specified by `tol_value` they belong to the same session window; otherwise a new session window is started automatically. 
 
 ```
 

docs/en/12-taos-sql/25-grant.md

@@ -9,15 +9,54 @@ This document describes how to manage permissions in TDengine.
 ## Create a User
 
 ```sql
-CREATE USER use_name PASS 'password';
+CREATE USER user_name PASS 'password' [SYSINFO {1|0}];
 ```
 
 This statement creates a user account.
 
-The maximum length of use_name is 23 bytes.
+The maximum length of user_name is 23 bytes.
 
 The maximum length of password is 128 bytes. The password can include leters, digits, and special characters excluding single quotation marks, double quotation marks, backticks, backslashes, and spaces. The password cannot be empty.
 
+`SYSINFO` indicates whether the user is allowed to view system information. `1` means allowed, `0` means not allowed. System information includes server configuration, dnode, vnode, storage. The default value is `1`.
+
+For example, we can create a user whose password is `123456` and is able to view system information.
+
+```sql
+taos> create user test pass '123456' sysinfo 1;
+Query OK, 0 of 0 rows affected (0.001254s)
+```
+
+## View Users
+
+To show the users in the system, please use 
+
+```sql
+SHOW USERS;
+```
+
+This is an example:
+
+```sql
+taos> show users;
+           name           | super | enable | sysinfo |       create_time       |
+================================================================================
+ test                     |     0 |      1 |       1 | 2022-08-29 15:10:27.315 |
+ root                     |     1 |      1 |       1 | 2022-08-29 15:03:34.710 |
+Query OK, 2 rows in database (0.001657s)
+```
+
+Alternatively, you can get the user information by querying a built-in table, INFORMATION_SCHEMA.INS_USERS. For example:
+
+```sql
+taos> select * from information_schema.ins_users;
+           name           | super | enable | sysinfo |       create_time       |
+================================================================================
+ test                     |     0 |      1 |       1 | 2022-08-29 15:10:27.315 |
+ root                     |     1 |      1 |       1 | 2022-08-29 15:03:34.710 |
+Query OK, 2 rows in database (0.001953s)
+```
+
 ## Delete a User
 
 ```sql
@@ -40,6 +79,13 @@ alter_user_clause: {
 - ENABLE: Specify whether the user is enabled or disabled. 1 indicates enabled and 0 indicates disabled.
 - SYSINFO: Specify whether the user can query system information. 1 indicates that the user can query system information and 0 indicates that the user cannot query system information.
 
+For example, you can use below command to disable user `test`:
+
+```sql
+taos> alter user test enable 0;
+Query OK, 0 of 0 rows affected (0.001160s)
+```
+
 
 ## Grant Permissions
 
@@ -62,7 +108,7 @@ priv_level : {
 }
 ```
 
-Grant permissions to a user.
+Grant permissions to a user, this feature is only available in enterprise edition.
 
 Permissions are granted on the database level. You can grant read or write permissions.
 
@@ -92,4 +138,4 @@ priv_level : {
 
 ```
 
-Revoke permissions from a user.
+Revoke permissions from a user, this feature is only available in enterprise edition.

docs/zh/12-taos-sql/06-select.md

@@ -356,7 +356,7 @@ SELECT ... FROM (SELECT ... FROM ...) ...;
 - 与非嵌套的查询语句相比，外层查询所能支持的功能特性存在如下限制：
   - 计算函数部分：
     - 如果内层查询的结果数据未提供时间戳，那么计算过程隐式依赖时间戳的函数在外层会无法正常工作。例如：INTERP, DERIVATIVE, IRATE, LAST_ROW, FIRST, LAST, TWA, STATEDURATION, TAIL, UNIQUE。
-    - 如果内层查询的结果数据不是有效的时间序列，那么计算过程依赖数据为时间序列的函数在外层会无法正常工作。例如：LEASTSQUARES, ELAPSED, INTERP, DERIVATIVE, IRATE, TWA, DIFF, STATECOUNT, STATEDURATION, CSUM, MAVG, TAIL, UNIQUE。
+    - 如果内层查询的结果数据不是按时间戳有序，那么计算过程依赖数据按时间有序的函数在外层会无法正常工作。例如：LEASTSQUARES, ELAPSED, INTERP, DERIVATIVE, IRATE, TWA, DIFF, STATECOUNT, STATEDURATION, CSUM, MAVG, TAIL, UNIQUE。
     - 计算过程需要两遍扫描的函数，在外层查询中无法正常工作。例如：此类函数包括：PERCENTILE。
 
 :::

source/dnode/mnode/impl/src/mndTrans.c

@@ -790,10 +790,20 @@ static bool mndCheckTransConflict(SMnode *pMnode, STrans *pNew) {
         if (mndCheckDbConflict(pNew->dbname1, pTrans)) conflict = true;
         if (mndCheckDbConflict(pNew->dbname2, pTrans)) conflict = true;
       }
+      if (pTrans->conflict == TRN_CONFLICT_DB_INSIDE) {
+        if (mndCheckDbConflict(pNew->dbname2, pTrans)) conflict = true; // for stb
+      }
     }
 
-    mError("trans:%d, can't execute since conflict with trans:%d, db1:%s db2:%s", pNew->id, pTrans->id, pTrans->dbname1,
-           pTrans->dbname2);
+    if (conflict) {
+      mError("trans:%d, db1:%s db2:%s type:%d, can't execute since conflict with trans:%d db1:%s db2:%s type:%d",
+             pNew->id, pNew->dbname1, pNew->dbname2, pNew->conflict, pTrans->id, pTrans->dbname1, pTrans->dbname2,
+             pTrans->conflict);
+    } else {
+      mDebug("trans:%d, db1:%s db2:%s type:%d, not conflict with trans:%d db1:%s db2:%s type:%d", pNew->id,
+             pNew->dbname1, pNew->dbname2, pNew->conflict, pTrans->id, pTrans->dbname1, pTrans->dbname2,
+             pTrans->conflict);
+    }
     sdbRelease(pMnode->pSdb, pTrans);
   }