Le mercredi 28 janvier 2026 à 12:33, Andrey Silitskiy <[email protected]> a écrit : > This is also possible in the current implementation, but your option offers > a simpler interface if we do not plan to add new wallsender completion > modes. > The naming of the parameter is also a question, because wal_sender_timeout > already exists (which also fits the name wal_sender_stop_timeout quite > well). > The difference between these parameters may not be obvious to users. > Thoughts?
The naming can probably be revisited but the use case I have in mind is the following: - we want to bound the time it takes to perform a restart, or a stop, with walsenders setup. - the immediate shutdown solves this problem - 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. Switching to wait_flush may be acceptable in that case, but then if the walreceiver does not catch up in time we're back to agressively stopping postgres to abort the waiting stop process, and the upgrade entirely. So in my mind having a timeout makes a lot more sense. What do you think ?
