Re: Handle infinite recursion in logical replication setup

On Wed, May 18, 2022 at 10:29 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, May 4, 2022 at 12:17 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > Thanks for the comments, the attached v13 patch has the changes for the same.
> >
>
> Few comments on v13-0001
> ======================
> 1.
> + *
> + * FIXME: LOGICALREP_PROTO_LOCALONLY_VERSION_NUM needs to be bumped to 4 in
> + * PG16.
> ...
> @@ -477,6 +489,12 @@ pgoutput_startup(LogicalDecodingContext *ctx,
> OutputPluginOptions *opt,
> else
> ctx->twophase_opt_given = true;
>
> + if (data->local_only && data->protocol_version <
> LOGICALREP_PROTO_LOCALONLY_VERSION_NUM)
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("requested proto_version=%d does not support local_only, need
> %d or higher",
> + data->protocol_version, LOGICALREP_PROTO_LOCALONLY_VERSION_NUM)));
>
> What is the need to change the protocol version for this parameter? As
> per my understanding, we only need a different protocol version when
> we are sending some new message or some additional information in an
> existing message as we have done for the streaming/two_phase options
> which doesn't seem to be the case here.

Modified

> 2.
> @@ -29,6 +29,7 @@ typedef struct PGOutputData
> bool streaming;
> bool messages;
> bool two_phase;
> + bool local_only;
> } PGOutputData;
>
> It seems we already have a similar option named 'only_local' in
> TestDecodingData which has the exactly same functionality. So, isn't
> it better to name this as 'only_local' instead of 'local_only'? Also,
> let's add a test case for 'only_local' option of test_decoding.

Modified and added test for only_local option of test_decoding.

Thanks for the comments, the attached v14 patch has the changes for the same.

Regards,
Vignesh