Connection slots reserved for replication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Connection slots reserved for replication

Alexander Kukushkin
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

replication_reserved_connections.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Connection slots reserved for replication

Masahiko Sawada
On Wed, Aug 1, 2018 at 9:30 PM, Alexander Kukushkin <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Connection slots reserved for replication

Alexander Kukushkin
Hi,

2018-09-14 12:23 GMT+02:00 Masahiko Sawada <[hidden email]>:

>> 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

Regards,
--
Alexander Kukushkin

replication_reserved_connections-v2.patch (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Connection slots reserved for replication

Kyotaro HORIGUCHI-2
Hello.

I agree to the objective.

At Mon, 17 Sep 2018 14:25:56 +0200, Alexander Kukushkin <[hidden email]> wrote in <CAFh8B=[hidden email]>

> Hi,
>
> 2018-09-14 12:23 GMT+02:00 Masahiko Sawada <[hidden email]>:
>
> >> 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


Reply | Threaded
Open this post in threaded view
|

Re: Connection slots reserved for replication

Alexander Kukushkin
Hi,

On 20 September 2018 at 08:18, Kyotaro HORIGUCHI
<[hidden email]> 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.

Regards,
--
Alexander Kukushkin

replication_reserved_connections-v3.patch (10K) Download Attachment