Re: Exit walsender before confirming remote flush in logical replication - Mailing list pgsql-hackers

From Japin Li
Subject Re: Exit walsender before confirming remote flush in logical replication
Date
Msg-id SY7PR01MB1092193C8AAAB9DD32341E72FB67CA@SY7PR01MB10921.ausprd01.prod.outlook.com
Whole thread Raw
In response to Re: Exit walsender before confirming remote flush in logical replication  (Andrey Silitskiy <a.silitskiy@postgrespro.ru>)
Responses Re: Exit walsender before confirming remote flush in logical replication
List pgsql-hackers
On Tue, 03 Mar 2026 at 14:08, Andrey Silitskiy <a.silitskiy@postgrespro.ru> wrote:
> On Feb 10, 2026 Ronan Dunklau <ronan(at)dunklau(dot)fr> wrote:
>> - however, if one were to stop the service before doing a pg_upgrade,
>> they would have no other choice than either disable the behaviour
>> entirely (by switching to wait_flush) or fail the upgrade if a logical
>> replication slot is pending changes.
>
> I agree with you, this idea is more flexible. So I changed the interface
> from the one discussed in this thread from the very beginning to a timeout.
> Propose an updated patch.
>
> Best Regards,
> Andrey
>

At first glance, wal_sender_shutdown_timeout seems to have the wrong type.
It should be an integer, not an enum.

+      <term><varname>wal_sender_shutdown_timeout</varname> (<type>enum</type>)

> [2. text/x-patch; v1-0001-Introduce-a-new-GUC-wal_sender_shutdown_timeout.patch]...

-- 
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: Don't keep closed WAL segment in page cache after replay
Next
From: Peter Geoghegan
Date:
Subject: Re: Correcting freeze conflict horizon calculation