On 08/26/2013 02:33 PM, Craig Ringer wrote:
> On 08/26/2013 08:15 PM, Hannu Krosing wrote:
>> On 08/26/2013 12:50 PM, Antonin Houska wrote:
>>>> On 08/22/2013 03:33 PM, Craig Ringer wrote:
>>>>>> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig wrote:
>>>>>>
>>>>>>>> what would be a reasonable scenario where limiting streaming would make sense? i cannot think of any to be
honest.
>>>>>> I tend to agree. If anything we're likely to want the reverse - the
>>>>>> ability to throttle WAL *generation* on the master so streaming can keep up.
>>>> (I assume you mean WAL *sending* rather than *generation*.)
>> I think he meant *generation*, that is making sure that no more
>> than X amount of WAL is generated in Y amount of time, thereby
>> making sure that you can stream less WAL without falling behind.
>>
>
> Exactly so.
>
> Sometimes one doesn't want the latency of synchronous replication, but
> still wants to set a limit on how far behind the standby can fall. It
> might be for limiting data loss, for making sure a replica can keep up
> sustainably, or just to make sure the replica never gets far enough
> behind that the master discards WAL that it still requires.
I think the question that brought us here was whether new functionality
of pg_basebackup should be implemented on server side, so that other
client applications - including the Barman that you mentioned in the
previous mail - don't have to duplicate it. Ability to throttle (one
time) transfer of all the files that standby setup requires falls into
this category.
However what you stress now is control of the (continuous) WAL stream
and thus something that affects normal operation, rather than setup. I
still think the pg_basebackup does not have to throttle the WAL stream,
so this your request does not overlap with the current patch.
// Antonin Houska (Tony)
