On Tue, 2021-06-15 at 15:19 +0900, Kyotaro Horiguchi wrote:
> I don't think the message is neded, but I don't oppose it as far as
> the level is LOG and the messages were changed as something like
> this:
>
>
> - elog(DEBUG1, "cannot stream from %X/%X, minimum is
> %X/%X, forwarding",
> + elog(LOG, "%X/%X has been already streamed,
> forwarding to %X/%X",
>
> FWIW, I most prefer #1. I see #2 as optional. and see #3 as the
> above.
Attached.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index bc2a2feb0b9..4543d772781 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2396,10 +2396,22 @@ The commands accepted in replication mode are:
<term><literal>START_REPLICATION</literal> <literal>SLOT</literal> <replaceable class="parameter">slot_name</replaceable> <literal>LOGICAL</literal> <replaceable class="parameter">XXX/XXX</replaceable> [ ( <replaceable>option_name</replaceable> [ <replaceable>option_value</replaceable> ] [, ...] ) ]</term>
<listitem>
<para>
- Instructs server to start streaming WAL for logical replication, starting
- at WAL location <replaceable class="parameter">XXX/XXX</replaceable>. The server can
- reply with an error, for example if the requested section of WAL has already
- been recycled. On success, server responds with a CopyBothResponse
+ Instructs server to start streaming WAL for logical replication,
+ starting at either WAL location <replaceable
+ class="parameter">XXX/XXX</replaceable> or the slot's
+ <literal>confirmed_flush_lsn</literal> (see <xref
+ linkend="view-pg-replication-slots"/>), whichever is greater. This
+ behavior makes it easier for clients to avoid updating their local LSN
+ status when there is no data to process. However, starting at a
+ different LSN than requested might not catch certain kinds of client
+ errors; so the client may wish to check that
+ <literal>confirmed_flush_lsn</literal> matches its expectations before
+ issuing <literal>START_REPLICATION</literal>.
+ </para>
+
+ <para>
+ The server can reply with an error, for example if the
+ slot does not exist. On success, server responds with a CopyBothResponse
message, and then starts to stream WAL to the frontend.
</para>
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index ffc6160e9f3..b3090979115 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -518,8 +518,12 @@ CreateDecodingContext(XLogRecPtr start_lsn,
* xlog records didn't result in anything relevant for logical
* decoding. Clients have to be able to do that to support synchronous
* replication.
+ *
+ * Starting at a different LSN than requested might not catch certain
+ * kinds of client errors; so the client may wish to check that
+ * confirmed_flush_lsn matches its expectations.
*/
- elog(DEBUG1, "cannot stream from %X/%X, minimum is %X/%X, forwarding",
+ elog(LOG, "%X/%X has been already streamed, forwarding to %X/%X"
LSN_FORMAT_ARGS(start_lsn),
LSN_FORMAT_ARGS(slot->data.confirmed_flush));
