Merge branch 'risingwavelabs:main' into main

Author: agiron123

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -2,7 +2,7 @@ name: Bug Report
 description: Noticed any typos, misused terms, inconsistencies, or ambiguities in the docs? Let us know!
 title: "Bug: "
 labels: ["bug"]
-assignees: [CharlieSYH, hengm3467]
+assignees: [WanYixian, ShanlanLi]
 body:
   - type: markdown
     attributes:

docs/guides/create-sink-kafka.md

@@ -72,6 +72,7 @@ When creating a Kafka sink in RisingWave, you can specify the following Kafka-sp
 |queue.buffering.max.kbytes |properties.queue.buffering.max.kbytes| int|
 |queue.buffering.max.messages |properties.queue.buffering.max.messages |int|
 |queue.buffering.max.ms |properties.queue.buffering.max.ms |float|
+|request.required.acks| properties.request.required.acks| int |
 |retry.backoff.ms |properties.retry.backoff.ms| int|
 |receive.message.max.bytes | properties.receive.message.max.bytes | int |
 |ssl.endpoint.identification.algorithm | properties.ssl.endpoint.identification.algorithm | str |

docs/guides/ingest-from-mysql-cdc.md

@@ -48,7 +48,7 @@ CREATE USER 'user'@'%' IDENTIFIED BY 'password';
 2. Grant the appropriate privileges to the user.
 
 ```sql
-GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'%';
+GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'%';
 ```
 
 3. Finalize the privileges.

docs/guides/sink-to-elasticsearch.md

@@ -2,14 +2,20 @@
 id: sink-to-elasticsearch
 title: Sink data from RisingWave to Elasticsearch
 description: Sink data from RisingWave to Elasticsearch.
-slug: /sink-to-elasticsearch 
+slug: /sink-to-elasticsearch
 ---
 You can deliver the data that has been ingested and transformed in RisingWave to Elasticsearch to serve searches or analytics.
 
 This guide describes how to sink data from RisingWave to Elasticsearch using the Elasticsearch sink connector in RisingWave.
 
 [Elasticsearch](https://www.elastic.co/elasticsearch/) is a distributed, RESTful search and analytics engine capable of addressing a growing number of use cases. It centrally stores your data for lightning-fast search, fine‑tuned relevancy, and powerful analytics that scale with ease.
 
+The Elasticsearch sink connecter in RisingWave will perform index operations via the [bulk API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html#docs-bulk-api-request), flushing updates whenever one of these criteria is met:
+
+- 1,000 operations
+- 5mb of updates
+- 5 seconds since the last flush (assuming new actions are queued)
+
 :::note Beta Feature
 The Elasticsearch sink connector in RisingWave is currently a Beta feature that supports only versions 7.x and 8.x of Elasticsearch. Please contact us if you encounter any issues or have feedback.
 :::
@@ -38,7 +44,7 @@ WITH (
   primary_key = '<primary key of the sink_from object>',
   { index = '<your Elasticsearch index>' | index_column = '<your index column>' },
   url = 'http://<ES hostname>:<ES port>',
-  username = '<your ES username>', 
+  username = '<your ES username>',
   password = '<your password>',
   delimiter='<delimiter>'
 );

docs/guides/sink-to-nats.md

@@ -37,8 +37,9 @@ WITH (
    connect_mode=<connect_mode>
    username='<your user name>',
    password='<your password>'
-   jwt=`<your jwt>`,
-   nkey=`<your nkey>`
+   jwt='<your jwt>',
+   nkey='<your nkey>',
+   type='<sink data type>'
 );
 ```
 
@@ -52,7 +53,7 @@ The NATS sink connector in RisingWave provides at-least-once delivery semantics.
 
 :::note
 
-According to the [NATS documentation](https://docs.nats.io/running-a-nats-service/nats_admin/jetstream_admin/naming), stream names must adhere to subject naming rules as well as being friendly to the file system. Here are the recommended guidelines for stream names:
+According to the [NATS documentation](https://docs.nats.io/running-a-nats-service/nats_admin/jetstream_admin/naming), stream names must adhere to subject naming rules as well as be friendly to the file system. Here are the recommended guidelines for stream names:
 
 - Use alphanumeric values.
 - Avoid spaces, tabs, periods (`.`), greater than (`>`) or asterisks (`*`).
@@ -72,3 +73,4 @@ According to the [NATS documentation](https://docs.nats.io/running-a-nats-servic
 |`connect_mode`|Required. Authentication mode for the connection. Allowed values: `plain`: No authentication; `user_and_password`: Use user name and password for authentication. For this option, `username` and `password` must be specified; `credential`: Use JSON Web Token (JWT) and NKeys for authentication. For this option, `jwt` and `nkey` must be specified.  |
 |`jwt` and `nkey`|JWT and NKEY for authentication. For details, see [JWT](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt) and [NKeys](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/nkey_auth).|
 |`username` and `password`| Conditional. The client user name and pasword. Required when `connect_mode` is `user_and_password`.|
+|`type`|Required. Sink data type. Its value should be `append-only`.|

docs/manage/view-configure-runtime-parameters.md

@@ -72,7 +72,7 @@ Below is the detailed information about the parameters you may see after using t
 | lock_timeout                          | 0               | See [here](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-LOCK-TIMEOUT) for details. Unused in RisingWave, support for compatibility.                                                                                                                                                            |
 | row_security                          | `true`/`false`            | See [here](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-ROW-SECURITY) for details. Unused in RisingWave, support for compatibility.                                                                                                                                                          |
 | standard_conforming_strings           | on              | See [here](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-STANDARD-CONFORMING-STRINGS)  for details.                                                                                                                                                                                              |
-| streaming_rate_limit                  | 0               | Set the maximum number of records per second per source, for each parallelism. The source here refers to an upstream source or snapshot read in the backfilling process.                                                                                                                                              |
+| streaming_rate_limit                  |  `default`/ A positive integer / `0`  | Set the maximum number of records per second per source, for each parallelism. The source here refers to an upstream source or snapshot read in the backfilling process.<br/><br/> `SET STREAMING_RATE_LIMIT TO 0` will pause the snapshot read stream for backfill and pause the source read for sources (Previously, this disabled the rate limit within the session). `SET STREAMING_RATE_LIMIT TO DEFAULT` will disable the rate limit within the session, but it will not change the rate limits of existing DDLs.                                                                                                                                              |
 | rw_streaming_over_window_cache_policy | full            | Cache policy for partition cache in streaming over window. Can be "full", "recent", "recent_first_n" or "recent_last_n".                                                                                                                                                                                     |
 | background_ddl                        | `true`/`false`           | Run DDL statements in background.                                                                                                                                                                                                                                                                               |
 | server_encoding                       | UTF8            | Show the server-side character set encoding. At present, this parameter can be shown but not set, because the encoding is determined at database creation time.                                                                                                                                               |
@@ -104,4 +104,4 @@ You can also use the [`ALTER SYSTEM SET`](/sql/commands/sql-alter-system.md) com
 
 ```sql title="Syntax"
 ALTER SYSTEM SET session_param_name TO session_param_value;
-```
+```

docs/sql/commands/sql-recover.md

@@ -0,0 +1,22 @@
+---
+id: sql-recover
+title: RECOVER
+description: Trigger recovery manually.
+slug: /sql-recover
+---
+<head>
+  <link rel="canonical" href="https://docs.risingwave.com/docs/current/sql-recover/" />
+</head>
+
+Use the `RECOVER` command to trigger an ad-hoc recovery manually. This is helpful when there is a high barrier latency and you need to force a recovery to activate. By doing this, commands like `CANCEL` or `DROP` can take effect immediately.
+
+
+```sql title="Syntax"
+RECOVER;
+```
+
+```sql title="Syntax"
+RECOVER;
+----RESULT
+RECOVER
+```

docs/sql/commands/sql-set-background-ddl.md

@@ -20,9 +20,9 @@ Use the `SET BACKGROUND_DDL` command to run Data Definition Language (DDL) opera
 SET BACKGROUND_DDL = { true | false };
 ```
 
-- When `BACKGROUND_DDL` is set to true, any subsequent DDL operations will be executed in the background, allowing you to proceed with other tasks.
+- By default, `BACKGROUND_DDL` is set as `false` to disable it, meaning that DDL operations will execute in the foreground. The commands `CREATE MATERIALIZED VIEW ON TABLE`, `CREATE MATERIALIZED VIEW ON MATERIALIZED VIEW`, `CREATE MATERIALIZED VIEW ON SOURCE` and `CREATE SINK` will only be executed once the backfilling process is completed.
 
-- When `BACKGROUND_DDL` is set to false (or not set at all), the DDL operations will execute in the foreground.
+- When `BACKGROUND_DDL` is set to `true`, any subsequent DDL operations will be executed in the background, allowing you to proceed with other tasks.
 
 ## Supported DDL operations
 

docs/sql/query-syntax/query-syntax-join-clause.md

@@ -112,7 +112,7 @@ ON s1.id = s2.id and s1.window_start = s2.window_start;
 
 ## Interval joins
 
-Window joins require that the two sources have the same window type and window size. This requirement can be too strict in some scenarios. If you want to join two sources that have some time offset, you can create an interval join by specifying an accepted internval range based on watermarks.
+Window joins require that the two sources have the same window type and window size. This requirement can be too strict in some scenarios. If you want to join two sources that have some time offset, you can create an interval join by specifying an accepted interval range based on watermarks.
 
 The syntax of an interval join is:
 
@@ -136,23 +136,27 @@ ON s1.id = s2.id and s1.ts between s2.ts and s2.ts + INTERVAL '1' MINUTE;
 
 ## Process-time temporal joins
 
-A temporal join is often used to widen a fact table. Its advantage is that it does not require RisingWave to maintain the join state, making it suitable for scenarios where the dimension table is not updated, or where updates to the dimension table do not affect the previously joined results. To further improve performance, you can use the index of a dimension table to form a join with the fact table.
+Process-time temporal joins are divided into two categories: append-only process-time temporal join and non-append-only process-time temporal join. Check the following instructions for their differences.
 
-### Syntax
+### Append-only process-time temporal join
+
+An append-only temporal join is often used to widen a fact table. Its advantage is that it does not require RisingWave to maintain the join state, making it suitable for scenarios where the dimension table is not updated, or where updates to the dimension table do not affect the previously joined results. To further improve performance, you can use the index of a dimension table to form a join with the fact table.
+
+#### Syntax
 
 ```sql
 <table_expression> [ LEFT | INNER ] JOIN <table_expression> FOR SYSTEM_TIME AS OF PROCTIME() ON <join_conditions>;
 ```
 
-### Notes
+#### Notes
 
 - The left table expression is an append-only table or source.
 - The right table expression is a table, index or materialized view.
 - The process-time syntax `FOR SYSTEM_TIME AS OF PROCTIME()` is included in the right table expression.
 - The join type is INNER JOIN or LEFT JOIN.
 - The Join condition includes the primary key of the right table expression.
 
-### Example
+#### Example
 
 If you have an append-only stream that includes messages like below:
 
@@ -179,11 +183,43 @@ You can use a temporal join to fetch the latest product name and price from the
 SELECT transaction_id, product_id, quantity, sale_date, product_name, price 
 FROM sales
 JOIN products FOR SYSTEM_TIME AS OF PROCTIME()
-ON product_id = id
+ON product_id = id WHERE process_time BETWEEN valid_from AND valid_to;
 ```
 
 | transaction_id | product_id | quantity | sale_date  | product_name | price |
 |----------------|------------|----------|------------|--------------|-------|
 | 1              | 101        | 3        | 2023-06-18 | Product A    | 25    |
 | 2              | 102        | 2        | 2023-06-19 | Product B    | 15    |
 | 3              | 101        | 1        | 2023-06-20 | Product A    | 22    |
+
+### Non-append-only process-time temporal join
+
+Compared to the append-only temporal join, the non-append-only temporal join can accommodate non-append-only input for the left table. However, it introduces an internal state to materialize the lookup result for each left-hand side (LHS) insertion. This allows the temporal join operator to retract the join result it sends downstream when update or delete messages arrive.
+
+#### Syntax
+
+The non-append-only temporal join shares the same syntax as the append-only temporal join.
+
+```sql
+<table_expression> [ LEFT | INNER ] JOIN <table_expression> FOR SYSTEM_TIME AS OF PROCTIME() ON <join_conditions>;
+```
+
+#### Example
+
+Now if you update the table `sales`:
+
+```sql
+UPDATE sales SET quantity = quantity + 1;
+```
+
+You will get these results:
+
+| transaction_id | product_id | quantity | sale_date | product_name | price |
+| --- | --- | --- | --- | --- | --- |
+| 1 | 101 | 4 | 2023-06-18 | Product A | 25 |
+| 2 | 102 | 3 | 2023-06-19 | Product B | 15 |
+| 3 | 101 | 2 | 2023-06-20 | Product A | 22 |
+
+:::note
+Every time you update the left-hand side table, it will look up the latest data from the right-hand side table.
+:::

docs/sql/syntax/sql-pattern-topn.md

@@ -69,12 +69,12 @@ INSERT INTO t (x, y, z) VALUES
 ```
 
 ```sql title="Run a top-N query"
-SELECT r1
+SELECT r
   FROM (
     SELECT
       *,
       row_number() OVER (PARTITION BY x ORDER BY y) r
     FROM t
   ) Q
-WHERE Q.r1 < 10;
+WHERE Q.r < 10;
 ```