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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Date: 2025-12-10 10:24:04
Message-ID: CAD21AoDfr05XSvcRxOfVzrc1Sbhwnn6GCeeDWxf4puK2PRE6dA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 10, 2025 at 2:07 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> Another thing I noticed in v34 is that, due to the change in
> show_effective_wal_level(), a standby now reports effective_wal_level
> = 'logical' when wal_level = 'logical' is set on the standby, even if
> the primary has effective_wal_level='replica'. Is this change in
> behavior intentional?
>
> It seems to contradict the documented behavior as well:
>
> + On standby servers, <varname>effective_wal_level</varname> matches
> + the value of <varname>effective_wal_level</varname> from the most
> + upstream server in the replication chain.

No, it should be fixed. Thank you for pointing this out.

> ~~
>
> I see that XLogLogicalInfoXactCache is removed, but it is still
> referenced at few places:
>
> +extern PGDLLEXPORT int XLogLogicalInfoXactCache;
>
> +/*
> + * A process local cache of LogicalDecodingCtl->xlog_logical_info. This is
> + * initialized at process startup time, and could be updated when absorbing
> + * the process barrier signal in ProcessBarrierUpdateXLogLogicalInfo().
> + * See the comments of XLogLogicalInfoXactCache too for details of how this
> + * cache value is used within a transaction.
> + */

Will fix.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nitin Jadhav 2025-12-10 10:31:28 Re: Fix crash during recovery when redo segment is missing
Previous Message Shlok Kyal 2025-12-10 10:21:53 Re: Skipping schema changes in publication