Re: Make wal_receiver_timeout configurable per subscription

On Fri, Feb 6, 2026 at 2:03 PM Chao Li <li.evan.chao@gmail.com> wrote:
> I applied the patch locally and played with it a bit. In short, it adds a new subscription option that allows overriding the GUC wal_receiver_timeout for a subscription’s apply worker. The changes look solid overall, and the new option worked as expected in my manual testing.

Thanks for the review!


> I have only one small comment:
> ```
> +                       /*
> +                        * Test if the given value is valid for wal_receiver_timeeout GUC.
> +                        * Skip this test if the value is -1, since -1 is allowed for the
> +                        * wal_receiver_timeout subscription option, but not for the GUC
> +                        * itself.
> +                        */
> +                       parsed = parse_int(opts->wal_receiver_timeout, &val, 0, NULL);
> +                       if (!parsed || val != -1)
> +                               (void) set_config_option("wal_receiver_timeout", opts->wal_receiver_timeout,
> +                                                                                PGC_BACKEND, PGC_S_TEST, GUC_ACTION_SET,
> +                                                                                false, 0, false);
> ```
>
> Here, parse_int() is also from GUC, with flag 0, it will reject any value with units such as “1s” or “7d”. So in practice, the only purpose of calling parse_int() here is to detect the special value “-1”.
>
> Given that, I think using atoi() directly may be simpler and easier to read. For example:

If we use atoi(), a command like CREATE SUBSCRIPTION with an invalid
wal_receiver_timeout value such as '-1invalid' would succeed, since atoi()
interprets it as -1. I don't think that's desirable behavior. So it would be
better to use parse_int() so that such invalid input is properly rejected.

Regards,

-- 
Fujii Masao