postgres logical replication slots

• https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/change-data-capture-in-postgres-how-to-use-logical-decoding-and/ba-p/1396421
• https://www.postgresql.org/docs/current/logicaldecoding-explanation.html
• https://www.postgresql.org/docs/current/logicaldecoding-walsender.html

Logical decoding outputs data changes as a stream. That stream is called a logical replication slot.

A slot represents a stream of changes that can be replayed to a client in the order they were made on the origin server.

A logical slot will emit each change just once in normal operation. The current position of each slot is persisted only at checkpoint, so in the case of a crash the slot may return to an earlier LSN, which will then cause recent changes to be sent again when the server restarts. Logical decoding clients are responsible for avoiding ill effects from handling the same message more than once. Clients may wish to record the last LSN they saw when decoding and skip over any repeated data or (when using the replication protocol) request that decoding start from that LSN rather than letting the server determine the start point. The Replication Progress Tracking feature is designed for this purpose, refer to replication origins.

Multiple independent slots may exist for a single database. Each slot has its own state, allowing different consumers to receive changes from different points in the database change stream.

A logical replication slot knows nothing about the state of the receiver(s). Only one receiver may consume changes from a slot at any given time.They will prevent removal of required resources even when there is no connection using them. This consumes storage because neither required WAL nor required rows from the system catalogs can be removed by VACUUM as long as they are required by a replication slot.

• Each slot has one output plugin (you choose which).
• Each slot provides changes from only one database.
• But a single database can have multiple slots.
• Each data change is normally emitted once per slot.
• However, if the Postgres instance restarts, a slot may re-emit changes. Your consumer needs to handle that situation.
• An unconsumed slot is a threat to your Postgres instance’s availability. If a slot’s stream isn’t being consumed, Postgres will hold on to all the WAL files for those unconsumed changes. This can lead to storage full or transaction ID wraparound.
• Postgres has a table called pg_replication_slots that tracks the state of all replication slots.
• consumer is any application that can connect to Postgres and ingest the logical decoding stream in ex pg_recvlogical