Re: Make wal_receiver_timeout configurable per subscription

On Fri, Feb 6, 2026 at 2:03 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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