Improve documentation for START_REPLICATION ... LOGICAL.
The starting point may not be exactly what the client requested; it may be at the slot's confirmed_flush_lsn. Also, upgrade the message from DEBUG1 to LOG when this happens. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/c5c861d576f2511732f8002c76245da587110b1c.camel%40j-davis.com
This commit is contained in:
parent
5fcf3945bd
commit
14d474e079
|
@ -2410,10 +2410,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>
|
||||
|
||||
|
|
|
@ -520,8 +520,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));
|
||||
|
||||
|
|
Loading…
Reference in New Issue