From: | Antonin Houska <antonin(dot)houska(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Backup throttling |
Date: | 2013-10-10 13:32:02 |
Message-ID: | 5256AC52.2040109@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
Attachment | Content-Type | Size |
---|---|---|
backup_throttling_v3.patch | text/x-patch | 14.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-10-10 13:34:59 | Long paths for tablespace leads to uninterruptible hang in Windows |
Previous Message | Merlin Moncure | 2013-10-10 13:25:39 | Re: PSQL return coder |