On Tue, Nov 6, 2018 at 9:16 PM Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > Hello. Thank you for the new version. > > At Thu, 1 Nov 2018 11:58:52 +0100, Alexander Kukushkin <cyberd...@gmail.com> > wrote in <CAFh8B=kax0uwdyzxn3xzpgrqhhrbiowwfhwstdg0fvj4is2...@mail.gmail.com> > > Hi, > > > > Attached rebased version patch to the current HEAD and created commit fest > > entry > > On Fri, 21 Sep 2018 at 13:43, Alexander Kukushkin <cyberd...@gmail.com> > > wrote: > > > > > > Hi, > > > > > > On 20 September 2018 at 08:18, Kyotaro HORIGUCHI > > > <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > > > > > > > > > Instaed, we can iterally "reserve" connection slots for the > > > > specific use by providing ProcGlobal->walsenderFreeProcs. The > > > > slots are never stolen for other usage. Allowing additional > > > > walsenders comes after all the slots are filled to grab an > > > > available "normal" slot, it works as the same as the current > > > > behavior when walsender_reserved_connectsions = 0. > > > > > > > > What do you think about this? > > > > > > Sounds reasonable, please see the updated patch. > > InitializeMaxBackends() > MaxBackends = MaxConnections + autovacuum_max_workers + 1 + > - max_worker_processes; > + max_worker_processes + replication_reserved_connections; > > This means walsender doesn't comsume a connection, which is > different from the current behavior. We should reserve a part of > MaxConnections for walsenders. (in PostmasterMain, > max_wal_senders is counted as a part of MaxConnections)
Yes. We can force replication_reserved_connections <= max_wal_senders and then reserved connections for replication should be a part of MaxConnections. > > + if (am_walsender && replication_reserved_connections < max_wal_senders > + && *procgloballist == NULL) > + procgloballist = &ProcGlobal->freeProcs; > > Currently exccesive number of walsenders are rejected in > InitWalSenderSlot and emit the following error. > > > ereport(FATAL, > > (errcode(ERRCODE_TOO_MANY_CONNECTIONS), > > errmsg("number of requested standby connections " > > "exceeds max_wal_senders (currently %d)", > > max_wal_senders))); > > With this patch, if max_wal_senders = > replication_reserved_connections = 3 and the fourth walreceiver > comes, we will get "FATAL: sorry, too many clients already" > instead. It should be fixed. > > When r_r_conn = 2 and max_wal_senders = 3 and the three > walsenders are active, in an exreme case where a new replication > connection comes at the same time another is exiting, we could > end up using two normal slots despite that one slot is vacant in > reserved slots. Doesn't the max_wal_senders prevent the case? Wal senders can get connection if we have free procs more than (MaxConnections - reserved for superusers). So I think for normal users the connection must be refused if (MaxConnections - (reserved for superuser and replication) > # of freeprocs) and for wal senders the connection also must be refused if (MaxConnections - (reserved for superuser) > # of freeprocs). I'm not sure we need such trick in InitWalSenderSlot(). Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATIONNTT Open Source Software Center