Re: Standby server with cascade logical replication could not be properly stopped under load

From: "G(dot) Sl" <skokoveshat(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, Alexey Makhmutov <a(dot)makhmutov(at)postgrespro(dot)ru>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Standby server with cascade logical replication could not be properly stopped under load
Date: 2025-12-29 05:22:18
Message-ID: CABPnX-ZoQ8Ow+ouVizAR-MWn1s26A05uU+LEYcXZS7AJFeyCTg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Michael ! Thx for clarifying.
No, I don't have a replica with logical slots, just a primary with logical
replication ( cdc debezium ) and sometimes it shutdown(restart) hangs until
killing of replication processes.
So it looks like I should investigate further and maybe, create a new issue.

On Mon, 29 Dec 2025 at 05:10, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Fri, Dec 26, 2025 at 04:14:17PM +0500, G. Sl wrote:
> > I've found the same behaviour in the 15.12 version. Any chances for
> > backpatch for this version ?
>
> As presented on this thread, the problem reported involves at least a
> cluster configuration A -> B -> C, where:
> - A is a primary.
> - B is a physical standby, streaming changes from A. In the test
> setup, this node includes replication slots, that have been created
> while the node is in standby mode. This action can only happen in v16
> and newer versions, where logical decoding on standbys has been added.
> - C is a primary node, streaming logical changes from B.
>
> Based on how the state of B required, this would not apply to v15
> because it is not possible to create replication slots on a standby.
> Also you may want to update to 15.15 first.
>
> I am open to arguments or discussions if you have found a new or
> different problem, of course, but there is nothing we can do without
> knowing more about your setup. An even better thing would be to have
> a reproducible test case based on v15 to understand your problem, but
> I can say for sure that we may be dealing with something different.
> Please feel free to refer to the top of the thread, which offers an
> excellent example of what a reproducible test case can be. By that I
> mean something that we can reuse and reproduce the issue.
>
> Also note that the change committed is 5231ed8262c9, that relies on
> the existence of am_cascading_walsender in XLogSendLogical() to not
> use GetFlushRecPtr() in all cases. Before the commit, we used
> GetStandbyFlushRecPtr() for that in v16. Again, v15 just uses
> GetFlushRecPtr(), but it should not be possible to find yourself in a
> position where XLogSendLogical() is called while on a standby, no?
> --
> Michael
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-12-29 06:00:01 BUG #19366: heap-use-after-free in pgaio_io_reclaim() detected with RELCACHE_FORCE_RELEASE
Previous Message Michael Paquier 2025-12-29 00:09:51 Re: Standby server with cascade logical replication could not be properly stopped under load