On 2025/05/20 18:13, vignesh C wrote:
If we set the wal_receiver_timeout configuration using ALTER ROLE for the subscription owner's role, the apply worker will start with that value. However, any changes made via ALTER ROLE ... SET wal_receiver_timeout will not take effect for an already running apply worker unless the subscription is disabled and re-enabled. In contrast, this is handled automatically during CREATE SUBSCRIPTION, where parameter changes are detected.
Yes, this is one of the limitations of the user-settable wal_receiver_timeout approach. If we want to change the timeout used by the apply worker without restarting it, storing the value in pg_subscription (similar to how synchronous_commit is handled) would be a better solution. In that case, for example, we could set the default value of pg_subscription.wal_receiver_timeout to -1, meaning the apply worker should use the global wal_receiver_timeout from postgresql.conf. If the value is 0 or higher, the apply worker would use the value stored in pg_subscription. On further thought, another downside of the user-settable approach is that it doesn't work for parameters like wal_retrieve_retry_interval, which is used by the logical replication launcher not the apply worker. So if we want to support per-subscription control for non-apply workers, storing the settings in pg_subscription might be more appropriate. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
