Hi, On 02/01/2019 10:21, Oleksii Kliukin wrote: > On Mon, Dec 17, 2018, at 14:10, Alexander Kukushkin wrote: >> Hi, >> >> On Thu, 6 Dec 2018 at 00:55, Petr Jelinek <petr.jeli...@2ndquadrant.com> >> wrote: >>>> Does excluding WAL senders from the max_connections limit and including >>>> max_wal_senders in MaxBackends also imply that we need to add >>>> max_wal_senders to the list at xlog.c: CheckRequiredParameterValues, >>>> requiring its value on the replica to be not lower than the one on the >>>> primary? >>>> >>> >>> I think it does, we need the proc slots for walsenders on the standby >>> same way we do for normal backends. >> >> You are absolutely right. Attaching the new version of the patch. > > Thank you. I've checked that the replica correctly complains when its value > of max_wal_senders is lower than the one on the primary at v6. > > As stated in my previous comment, I think we should retain the specific error > message on exceeding max_wal_senders, instead of showing the generic "too > many clients already'. Attached is the patch that fixes this small thing. > I've also rebased it against the master and took a liberty of naming it v7. > It makes me wondering why don't we apply the same level of details to the > regular out of connection message and don't show the actual value of > max_connections in the error text? >
+1 The patch generally looks good, but the documentation of max_wal_senders needs updating. In config.sgml we say: > WAL sender processes count towards the total number > of connections, so this parameter's value must be less than > <xref linkend="guc-max-connections"/> minus > <xref linkend="guc-superuser-reserved-connections"/>. This is now misleading. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
