On Wed, Aug 1, 2018 at 9:30 PM, Alexander Kukushkin <cyberd...@gmail.com> wrote: > Hello hackers, > > at the moment it is possible to reserve some amount of connection slots for > superusers and this behavior is controlled by superuser_reserved_connections > configuration parameter with the default value = 3. > > In case if all non-reserved connection slots are busy, replica fails to open > a new connection and start streaming from the primary. Such behavior is very > bad if you want to run postgresql HA clusters
Yeah, that's also bad if we want to use pg_baseback in the situation. > > Initially, replication connections required superuser privileges (in 9.0) > and therefore they were deliberately excluded from > superuser_reserved_connections. Basically that means it has never been > possible to reserve come connection slots for replication connections. > > Later (9.1) it became possible to create a user with REPLICATION and > NOSUPERUSER options, but comment in the postinit.c still tells that > superuser is required. > > Now I think now it is a time to go further, and we should make it possible > to reserve some connection slots for replication in a manner similar to > superuser connections. > +1 > How should it work: > 1. If we know that we got the replication connection, we just should make > sure that there are at least superuser_reserved_connections free connection > slots are available. > 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? > > And the last question how to control the number of reserved slots for > replication. There are two options: > 1. We can introduce a new GUC for that: replication_reserved_connections > 2. Or we can just use the value of max_wal_senders > > Personally, I more like the second option. > 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. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
