Re: Perform streaming logical transactions by background workers and parallel apply

On Mon, Jan 23, 2023 at 8:47 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jan 20, 2023 at 11:48 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > >
> > > Yet another way is to use the existing parameter logical_decode_mode
> > > [1]. If the value of logical_decoding_mode is 'immediate', then we can
> > > immediately switch to partial serialize mode. This will eliminate the
> > > dependency on timing. The one argument against using this is that it
> > > won't be as clear as a separate parameter like
> > > 'stream_serialize_threshold' proposed by the patch but OTOH we already
> > > have a few parameters that serve a different purpose when used on the
> > > subscriber. For example, 'max_replication_slots' is used to define the
> > > maximum number of replication slots on the publisher and the maximum
> > > number of origins on subscribers. Similarly,
> > > wal_retrieve_retry_interval' is used for different purposes on
> > > subscriber and standby nodes.
> >
> > Using the existing parameter makes sense to me. But if we use
> > logical_decoding_mode also on the subscriber, as Shveta Malik also
> > suggested, probably it's better to rename it so as not to confuse. For
> > example, logical_replication_mode or something.
> >
>
> +1. Among the options discussed, this sounds better.

Yeah, this looks better option with the parameter name
'logical_replication_mode'.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com