Re: Backup throttling

On 10/09/2013 08:56 PM, Robert Haas wrote:
> There seem to be several review comments made since you posted this
> version.  I'll mark this Waiting on Author in the CommitFest
> application, since it seems that the patch needs to be further
> updated.

Since it was waiting for reviewer, I was not sure whether I should wait
for his findings and fix everything in a single transaction.
Nevertheless, the next version is attached here.

It fixes findings reported in
http://www.postgresql.org/message-id/20130903165652.GC5227@eldon.alvh.no-ip.org

As for units
http://www.postgresql.org/message-id/20130903224127.GD7018@awork2.anarazel.de
I'm not convinced about "MB" at the moment. Unfortunately I couldn't
find any other command-line PG utility requiring amount of data as an
option. Thus I use single-letter suffix, just as wget does for the same
purposes.

As for this
http://www.postgresql.org/message-id/20130903125155.GA18486@awork2.anarazel.de
there eventually seems to be a consensus (I notice now the discussion
was off-list):

> On 2013-09-03 23:21:57 +0200, Antonin Houska wrote:
>> On 09/03/2013 02:51 PM, Andres Freund wrote:
>>
>>>
>>> It's probably better to use latches for the waiting, those have properly
>>> defined interruption semantics. Whether pg_usleep will be interrupted is
>>> platform dependant...
>>
>> I noticed a comment about interruptions around the definition of
>> pg_usleep() function, but concluded that the sleeps are rather frequent
>> in this applications (typically in the order of tens to hundreds per
>> second, although the maximum of 256 might need to be decreased).
>> Therefore occasional interruptions shouldn't distort the actual rate
>> much. I'll think about it again. Thanks,
>
> The issue is rather that you might not get woken up when you want to
> be. Signal handlers in postgres tend to do a
> SetLatch(&MyProc->procLatch); which then will interrupt sleeps done via
> WaitLatch(). It's probably not that important with the duration of the
> sleeps you have.
>
> Greetings,
>
> Andres Freund

// Antonin Houska (Tony)