Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

On Wed, Jan 22, 2025 at 2:04 AM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Mon, Jan 06, 2025 at 10:32:52PM -0800, Masahiko Sawada wrote:
> > On Mon, Jan 6, 2025 at 3:20 AM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > On Sat, Jan 4, 2025 at 6:03 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > >
> > > > On Fri, Jan 3, 2025 at 6:31 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> > > > >
> > > > > On Fri, Jan 3, 2025, at 10:14 AM, Bertrand Drouvot wrote:
> > > > >
> > > > > If we don't want to force wal_level = logical to enable logical decoding (your
> > > > > second idea) then I think that it would be better to "hide" everything behind
> > > > > logical replication slot creation / deletion. That would mean that having at
> > > > > least one logical replication slot created would be synonym to "activate logical
> > > > > decoding" and zero logical replication slot created would be synonym to "deactivate
> > > > > logical decoding".
> > > > >
> > > > >
> > > > > I like this idea. The logical replication slot existence already has the
> > > > > required protections and guarantees (no running transactions from the past while
> > > > > creating) for logical decoding.
> > > >
> > > > I agree that it's better behavior.
> > > >
> > > > >
> > > > > Having said that, you are basically folding 'logical' machinery into 'replica'.
> > > > > The 'logical' option can still exists but it will be less attractive because it
> > > > > increases the WAL volume even if you are not using logical replication. I don't
> > > > > know if the current 'logical' behavior (WAL records for logical decoding even
> > > > > if there is no active logical replication) has any use case (maybe someone
> > > > > inspects these extra records for analysis) but one suggestion (separate patch)
> > > > > is to make 'logical' synonymous with the new 'replica' behavior (logical
> > > > > decoding capability). This opens the door to remove 'logical' in future
> > > > > releases (accepted as synonym but not documented).
> >
> > FYI one possible use case of the 'logical' level would be that if we
> > support retrieving WAL records for logical decoding from somewhere
> > like restore_command in the future, users would like to keep the
> > wal_level 'logical' or keep the logical decoding active.
>
> Another use case is to allow logical decoding from standby. One could set
> wal_level to logical on the primary to be able to create a logical replication
> slot on the standby (without having the need to create one on the primary).

Good point. It seems to be a substantial disadvantage for users.

>
> BTW, currently it's mandatory to set wal_level to logical on the primary to
> be able to create a logical replication slot on the standby. Should we extend
> this to "logical decoding is enabled on the primary" too?

Yes, in order to use the logical decoding on standbys, we need to
enable it on the primary. When enabling the logical decoding on the
primary we can write a WAL record so that standby servers can enable
the logical decoding too.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com