Re: Make wal_receiver_timeout configurable per subscription

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-19T15:19:48Z
Lists: pgsql-hackers
On Mon, May 19, 2025 at 2:48 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> The GUC wal_receiver_interval is also used for physical replication
> and logical launcher, so won't making it userset can impact those
> cases as well, but maybe that is okay. However, for the specific case
> you are worried about, isn't it better to make it a subscription
> option as that won't have a chance to impact any other cases?

The advantage of Fujii-san's proposal is that it is very simple to
implement. A subscription option would indeed be better, but it would
also be considerably more complex. Why not start simple and if someone
wants to do the work to add something more complicated, that is fine?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add per-subscription wal_receiver_timeout setting.

  2. Make GUC wal_receiver_timeout user-settable.