| From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
|---|---|
| To: | 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 14:33:44 |
| Message-ID: | DE372F7B-8703-4B24-9BB6-CCF9B9F611CC@hintbits.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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?
Cheers,
Oleksii
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-12-05 15:24:46 | Re: don't mark indexes invalid unnecessarily |
| Previous Message | Julien Demoor | 2018-12-05 14:16:37 | Re: NOTIFY and pg_notify performance when deduplicating notifications |