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.jelinek@2ndquadrant.com> wrote:
>>>> Does excluding WAL senders from the max_connections limit and including max_wal_senders in MaxBackends also imply
thatwe need to add max_wal_senders to the list at xlog.c: CheckRequiredParameterValues, requiring its value on the
replicato 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
onthe primary at v6.
>
> As stated in my previous comment, I think we should retain the specific error message on exceeding max_wal_senders,
insteadof showing the generic "too many clients already'. Attached is the patch that fixes this small thing. I've also
rebasedit against the master and took a liberty of naming it v7. It makes me wondering why don't we apply the same
levelof details to the regular out of connection message and don't show the actual value of max_connections in the
errortext?
>
+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
