Fix wording of logical decoding concepts

Be specific about conditions under which we emit >1 copy of message

Craig Ringer
This commit is contained in:
Simon Riggs 2016-09-03 16:19:11 +01:00
parent 39b691f251
commit 0c40ab3a88
1 changed files with 15 additions and 3 deletions

View File

@ -12,7 +12,6 @@
<para>
Changes are sent out in streams identified by logical replication slots.
Each stream outputs each change exactly once.
</para>
<para>
@ -204,8 +203,7 @@ $ pg_recvlogical -d postgres --slot test --drop-slot
In the context of logical replication, a slot represents a stream of
changes that can be replayed to a client in the order they were made on
the origin server. Each slot streams a sequence of changes from a single
database, sending each change exactly once (except when peeking forward
in the stream).
database.
</para>
<note>
@ -221,6 +219,20 @@ $ pg_recvlogical -d postgres --slot test --drop-slot
independently of the connection using them and are crash-safe.
</para>
<para>
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 resent 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 <link linkend="replication-origins">replication origins</link>.
</para>
<para>
Multiple independent slots may exist for a single database. Each slot has
its own state, allowing different consumers to receive changes from