From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Oleksii Kliukin <alexk(at)hintbits(dot)com>, Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, magnus(at)hagander(dot)net, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Connection slots reserved for replication |
Date: | 2018-12-05 23:55:09 |
Message-ID: | 45d73681-0373-1b69-cacc-ab2668d51bb6@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/12/2018 15:33, Oleksii Kliukin wrote:
>
>> On 30. Nov 2018, at 13:58, Alexander Kukushkin <cyberdemn(at)gmail(dot)com> wrote:
>>
>> attaching the new version of the patch.
>> Now it simply reserves max_wal_senders slots in the ProcGlobal, what
>> guarantees that only walsender process could use them.
>
> With this patch It looks like InitProcess will trigger the generic error about 'too many clients' before the more specific error message in InitWalSenderSlot when exceeding the number of max_wal_senders.
>
> 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.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Glukhov | 2018-12-06 00:00:07 | Re: [PATCH] Opclass parameters |
Previous Message | Andres Freund | 2018-12-05 22:52:13 | Wrong parent node for WCO expressions in nodeModifyTable.c? |