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 →
-
Add per-subscription wal_receiver_timeout setting.
- fb80f388f4a1 19 (unreleased) landed
-
Make GUC wal_receiver_timeout user-settable.
- 8a6af3ad0879 19 (unreleased) landed