On 2013-08-22 07:39:41 +0200, PostgreSQL - Hans-Jürgen Schönig wrote:
> >> regarding the client side implementation: we have chosen this way because it is less invasive.
> >> i cannot see a reason to do this on the server side because we won't have 10
> >> pg_basebackup-style tools making use of this feature anyway.
> >
> > The problem is that receiver side throttling over TCP doesn't always
> > work all that nicely unless you have a low rate of transfer and/or very
> > low latency . Quite often you will have OS buffers/the TCP Window being
> > filled in bursts where the sender sends at max capacity and then a
> > period where nothing happens on the sender. That's often not what you
> > want when you need to throttle.
> >
> > Besides, I can see some value in e.g. normal streaming replication also
> > being rate limited...
> >
>
>
> what would be a reasonable scenario where limiting streaming would make sense? i cannot think of any to be honest.
It's not an unreasonable goal if you have several streaming replicas
with only some of them being synchronous replicas. Also, analytics
replicas that need to catchup don't really need priority over local
operations.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services