Re: pgbench: could not connect to server: Resource temporarily unavailable
От | Junwang Zhao |
---|---|
Тема | Re: pgbench: could not connect to server: Resource temporarily unavailable |
Дата | |
Msg-id | CAEG8a3L=7gVapJoGaFQWu83MvDAebe6SswjWKeoXdb66vxDA=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgbench: could not connect to server: Resource temporarily unavailable (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Ok, thanks for the clarification. On Tue, Aug 23, 2022 at 11:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Junwang Zhao <zhjwpku@gmail.com> writes: > > Just curious, *backlog* defines the maximum pending connections, > > why do we need to double the MaxConnections as the queue size? > > The postmaster allows up to twice MaxConnections child processes > to exist, per the comment in canAcceptConnections: > > * We allow more connections here than we can have backends because some > * might still be authenticating; they might fail auth, or some existing > * backend might exit before the auth cycle is completed. The exact > * MaxBackends limit is enforced when a new backend tries to join the > * shared-inval backend array. > > You can argue that 2X might not be the right multiplier, and you > can argue that the optimal listen queue length might be more or > less than the limit on number of child processes, but that's how > we've historically done it. I'm not especially interested in > changing that without somebody making a well-reasoned case for > some other number. > > regards, tom lane -- Regards Junwang Zhao
В списке pgsql-performance по дате отправления: