Hello. I agree to the objective.
At Mon, 17 Sep 2018 14:25:56 +0200, Alexander Kukushkin <cyberd...@gmail.com> wrote in <CAFh8B=nbh4gbfcit-jpjth60qjc1pkowkvgke+7di-fgadu...@mail.gmail.com> > Hi, > > 2018-09-14 12:23 GMT+02:00 Masahiko Sawada <sawada.m...@gmail.com>: > > >> 2. If we know that this is neither superuser nor replication connection, we > >> should check that there are at least (superuser_reserved_connections + > >> NumWalSenders() - max_wal_senders) connection slots are available. > > > > You wanted to mean (superuser_reserved_connections + max_wal_senders - > > NumWalSenders()) in the second point? > > Sure, my bad. Did a mistake when writing an email, but in the attached > file it looks good. > > > > > One argrable point of the second option could be that it breaks > > backward compatibility of the parameter configurations. That is, the > > existing systems need to re-configure the max_connections. So it might > > be better to take the first option with > > replication_reservd_connections = 0 by default. > > Please find attached the new version of the patch, which introduces > replication_reservd_connections GUC With this patch, non-superuser is rejected if there are less than super_res_conn + (remain of repl_res_conn). It gives the same effect for walsenders with just sharing superuser_reserved_connection by superusers and walsenders. 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? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
