-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Doc fetch from cursor
to be non-blocking and blocking
#23
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rest LGTM
delivery/subscription.mdx
Outdated
@@ -83,33 +83,39 @@ If you specify `FULL` instead of the `since_clause`, the subscription cursor sta | |||
FETCH from cursor function is currently only supported in the PSQL simple query mode. If you are using components like JDBC that default to the extended query mode, please manually set the mode to simple query mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extended mode is also supported in risingwavelabs/risingwave#17821 starting from v2.0
delivery/subscription.mdx
Outdated
(1 row) | ||
``` | ||
|
||
The `op` column in the result stands for the change operations. It has four options: `insert`, `update_insert`, `delete`, and `update_delete`. For a single UPDATE statement, the subscription log will contain two separate rows: one with `update_insert` and another with `update_delete`. This is because RisingWave treats an UPDATE as a delete of the old value followed by an insert of the new value. As for `rw_timestamp`, it corresponds to the Unix timestamp in milliseconds when the data was written. | ||
In the example above, the `op` column in the result indicates the type of change operations. There are four options: `insert`, `update_insert`, `delete`, and `update_delete`. For a single UPDATE statement, the subscription log will contain two separate rows: one with `update_insert` and another with `update_delete`. This is because RisingWave treats an UPDATE as a delete of the old value followed by an insert of the new value. As for `rw_timestamp`, it corresponds to the Unix timestamp in milliseconds when the data was written. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The four options are in camelCase instead of snake_case: Insert
, Delete
, UpdateInsert
, UpdateDelete
.
delivery/subscription.mdx
Outdated
|
||
Note that each time `FETCH NEXT FROM cursor_name` is called, it will return one row of incremental data from the subscribed table. It does not return all the incremental data at once, but requires the user to repeatedly call this statement to fetch the data. | ||
```sql | ||
FETCH NEXT/n FROM cursor_name WITH (timeout = 'xx'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's give a concrete example for timeout: replace timeout = 'xx'
to timeout = '1s'
Description
Doc
fetch from cursor
to be non-blocking and blockingRelated code PR
risingwavelabs/risingwave#18675
Related doc issue
Resolve https://github.com/risingwavelabs/risingwave-docs/issues/2672