DOCS-1109-document-himesh-bdr-wait_node_confirm_lsn

[djw-m]

Signed-off-by: Dj Walker-Morgan [email protected]

What Changed?

Added bdr.wait_node_confirm_lsn

[github-actions]

🚀 Deployed on https://deploy-preview-6228--edb-docs-staging.netlify.app

[djw-m]

How is the user supposed to know which (slot or pg_progression) is being used when you’ve left it open that either could be being used.

…

On Wed, 13 Nov 2024 at 06:21, sumarjee ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In product_docs/docs/pgd/5.6/reference/functions.mdx <#6228 (comment)>: > +| `target_lsn` | LSN to wait for. If NULL, uses the current write LSN on the local node. | + +### `bdr.wait_node_confirm_lsn` + +Wait until a node passes a certain LSN. + +This function allows you to wait until the last write on this session was replayed to one or all nodes. + +Upon being called, the function waits for a node to pass a certain LSN. +If no LSN is supplied, the current wal_flush_lsn (using the `pg_current_wal_flush_lsn()` function) position is used on the local node. +Supplying a node name parameter tells the function to wait for that node to pass the LSN. +If no node name is supplied (by passing NULL), the function waits until all the nodes pass the LSN, + +The function operates by polling every 1000 ms for changes from other nodes. Those changes are detected either by looking up the `confirmed_flush_lsn` from the node's replication slot or by connecting to the node directly and querying the results of `pg_replication_origin_progress()`, passing the local node as origin. + +If you are confirming a specific node and the node is concurrently dropped, the wait for that node is ended. If a node is currently down, isn't updating or is simply not able to be connected to, the wait will continue indefinately. To avoid this, set the statement_timeout to the maximum amount of time you are prepared to wait. If changes are detected by looking up the confirmed_flush_lsn from the node's replication slot and the slot is dropped concurrently, the wait ends for that node. If changes are detected by connecting to the node directly and querying the results of pg_replication_origin_progress(), and the node is currently down, the wait will continue indefinately. To avoid this, set the statement_timeout to the maximum amount of time you are prepared to wait. — Reply to this email directly, view it on GitHub <#6228 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6E5CBZ6YYR2XOIYZJXJO232ALVVTAVCNFSM6AAAAABRTWA7VGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIMZRHE4DSMRXG4> . You are receiving this because you were assigned.Message ID: ***@***.***>

[sumarjee]

looks fine to me