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.bapat.oss@gmail.com> wrote:
> >
> > On Sat, Jan 4, 2025 at 6:03 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On Fri, Jan 3, 2025 at 6:31 AM Euler Taveira <euler@eulerto.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).
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?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
