Subject: Re: BUG #18985: fast shutdown does not close connections from qlik data gateway data movement aka. replicate

From: Tom Lane <[email-masked]>
Date: Tue, 15 Jul 2025 12:08:21 -0400

=?UTF-8?Q?Erik_Dob=C3=A1k?= <[email-masked]> writes:
> On Tue, 15 Jul 2025, 16:35 David G. Johnston, <[email-masked]>
> wrote:
>> Can you replicate this on a supported version of PostgreSQL?

> 14.18 is afaik supported. it is runn:ng on 14.8. so yes i could replicate
> this on a supported version.

I think what David is actually wondering about is "Qlik Data Gateway
Data Movement".  That is not our code, and if it's using a custom
logical-replication plugin then the plugin seems like the likely
thing to blame.  We have not heard reports of this happening with
our stock replication code.

			regards, tom lane

---

From: Erik Dobák <[email-masked]>
Date: Tue, 15 Jul 2025 18:22:21 +0200

> our stock replication code.

hi Tom,

not sure what you mean by "plugin".

dgdm is connecting to an untempered postgres db = standard postres db
installation afaik.

did not know about plugins in postgres. how would one check if there is
some?

E

---

From: "David G. Johnston" <[email-masked]>
Date: Tue, 15 Jul 2025 09:27:36 -0700

> our stock replication code.

No, I meant the reported 14.8 PG version.

The observed behavior of the server seems like a bug no matter how
well-coded or not the software trying to make the connecting is.  The
server should be able to close and disallow clients no matter what they are
doing.

David J.

---

From: Tom Lane <[email-masked]>
Date: Tue, 15 Jul 2025 14:00:21 -0400

> server should be able to close and disallow clients no matter what they are

We will SIGKILL recalcitrant children during an "immediate" shutdown.
"Fast" shutdown is not defined to do that, and should not do so
because it'd imply having to do an unclean restart later.

I just tested logical replication both ways between current master and
v14 branch tip, and in either case the publishing server stops pretty
much instantaneously after "pg_ctl stop -m fast".  So I don't see
anything broken about our code, and I remain of the opinion that Qlik
is probably at fault.

			regards, tom lane

---

From: Tom Lane <[email-masked]>
Date: Tue, 15 Jul 2025 14:27:02 -0400

> did not know about plugins in postgres. how would one check if there is

Check the pg_replication_slots view on the publisher for the slot(s)
being used for Qlik replication.  If the "plugin" column says
something other than "pgoutput" then a nonstandard plugin is being
used.

			regards, tom lane

---

From: "David G. Johnston" <[email-masked]>
Date: Tue, 15 Jul 2025 11:28:08 -0700

> anything broken about our code, and I remain of the opinion that Qlik

Ok, yeah.  Looking more closely the reconnection attempt in the log doesn't
look related to this so those hung connections are not playing nicely when
told to go away.  Which indeed in fast mode we have to rely upon.

David J.

---

From: Erik Dobák <[email-masked]>
Date: Tue, 15 Jul 2025 20:32:53 +0200

> anything broken about our code, and I remain of the opinion that Qlik
thank you Tom,

based on the documentation mentioned in my initial post i was thinking that
the connections are closed during " fast" shutdown immediately.

i will forward this to Qlik then.

is there a better documentation that would explain the process of shutdown
than the link i posted above?

regards

E

---

From: Erik Dobák <[email-masked]>
Date: Tue, 15 Jul 2025 20:38:46 +0200

nice thanks i will study that.
E

---

From: Anthonin Bonnefoy <[email-masked]>
Date: Wed, 25 Feb 2026 10:08:32 +0100

Hi,

This is likely related to the issue I've reported[1]: A logical
walsender may be stuck at 100% CPU during shutdown, trying to read an
incomplete FPI_FOR_HINT record and blocking the shutdown sequence. By
stopping the logical replication's target, the impacted walsender
exited, unblocking the shutdown.

There are similar reports of failover being stuck on projects like patroni[2].

I've provided a way to reproduce the issue in the linked thread, along
with a tentative patch.

Regards,
Anthonin Bonnefoy

[1]: https://www.postgresql.org/message-id/flat/CAO6_Xqo3co3BuUVEVzkaBVw9LidBgeeQ_2hfxeLMQcXwovB3GQ%40mail.gmail.com
[2]: https://github.com/patroni/patroni/issues/3522