On Aug 21, 2013, at 10:57 AM, Andres Freund wrote:
> On 2013-08-21 08:10:42 +0200, PostgreSQL - Hans-Jürgen Schönig wrote:
>>
>> On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
>>
>>> On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
>>>> 2013-08-19 19:20 keltezéssel, Andres Freund írta:
>>>>> Hi,
>>>>>
>>>>> On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
>>>>>> Hello,
>>>>>> the purpose of this patch is to limit impact of pg_backup on running server.
>>>>>> Feedback is appreciated.
>>>>> Based on a quick look it seems like you're throttling on the receiving
>>>>> side. Is that a good idea? Especially over longer latency links, TCP
>>>>> buffering will reduce the effect on the sender side considerably.
>>>
>>>> Throttling on the sender side requires extending the syntax of
>>>> BASE_BACKUP and maybe START_REPLICATION so both can be
>>>> throttled but throttling is still initiated by the receiver side.
>>>
>>> Seems fine to me. Under the premise that the idea is decided to be
>>> worthwile to be integrated. Which I am not yet convinced of.
>>
>> i think there is a lot of value for this one. the scenario we had a couple of times is pretty simple:
>> just assume a weak server - maybe just one disk or two - and a slave.
>> master and slave are connected via a 1 GB network.
>> pg_basebackup will fetch data full speed basically putting those lonely disks out of business.
>> we actually had a case where a client asked if "PostgreSQL is locked during base backup". of
>> course it was just disk wait caused by a full speed pg_basebackup.
>
>> 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.
regards,
hans
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
