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
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.
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.
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.
Attached patch implements above described functionality.
Feedback is very appretiated.
Regards,
--
Alexander Kukushkin