On 02/27/2014 11:04 PM, Alvaro Herrera wrote:
> I pushed this patch with a few further tweaks. In your changes to
> address the above point, you made the suffix mandatory in the
> pg_basebackup -r option. This seemed a strange restriction, so I
> removed it. It seems more user-friendly to me to
Antonin Houska escribió:
> > Why did you choose "bytes per second" as a valid rate which we can specify?
> > Since the minimum rate is 32kB, isn't it better to use "KB per second" for
> > that?
> > If we do that, we can easily increase the maximum rate from 1GB to very
> > large
> > number in th
On 01/31/2014 06:26 AM, Fujii Masao wrote:
>> Is there a good place to define the constant, so that both backend and
>> client can use it? I'd say 'include/common' but no existing file seems
>> to be appropriate. I'm not sure if it's worth to add a new file there.
>
> If there is no good place to
On Tue, Jan 21, 2014 at 1:10 AM, Antonin Houska
wrote:
> On 01/15/2014 10:52 PM, Alvaro Herrera wrote:
>> I gave this patch a look. There was a bug that the final bounds check
>> for int32 range was not done when there was no suffix, so in effect you
>> could pass numbers larger than UINT_MAX and
I realize the following should be applied on the top of v7:
index a0216c1..16dd939 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -1263,7 +1263,7 @@ throttle(size_t increment)
throttling_counter %= throttling_sample;
/* Once the (po
On 01/15/2014 10:52 PM, Alvaro Herrera wrote:
> I gave this patch a look. There was a bug that the final bounds check
> for int32 range was not done when there was no suffix, so in effect you
> could pass numbers larger than UINT_MAX and pg_basebackup would not
> complain until the number reached
On Fri, Jan 17, 2014 at 5:03 AM, Andres Freund wrote:
> slightly related: we should start to reuse procLatch for walsenders
> instead of having a separate latch someday.
+ 1 on that.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Thu, Jan 16, 2014 at 12:03 PM, Andres Freund wrote:
> slightly related: we should start to reuse procLatch for walsenders
> instead of having a separate latch someday.
+1. The potential for bugs from failing to account for this within
signal handlers seems like a concern. I think that every pr
Hi,
On 2014-01-15 18:52:32 -0300, Alvaro Herrera wrote:
> Another thing I found a bit strange was the use of the latch. What this
> patch does is create a separate latch which is used for the throttling.
> This means that if the walsender process receives a signal, it will not
> wake up if it's s
Alvaro Herrera escribió:
> Antonin Houska escribió:
> > Thanks for checking. The new version addresses your findings.
>
> I gave this patch a look.
BTW I also moved the patch the commitfest currently running, and set it
waiting-on-author.
Your move.
--
Álvaro Herrerahttp://www.
Thanks for checking. The new version addresses your findings.
// Antonin Houska (Tony)
On 12/09/2013 03:49 PM, Fujii Masao wrote:
> On Fri, Dec 6, 2013 at 6:43 PM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> 2013-12-05 15:36 keltezéssel, Antonin Houska írta:
>>
>>> On 12/02/2013 02:23 PM, Boszormenyi
On Fri, Dec 6, 2013 at 6:43 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> 2013-12-05 15:36 keltezéssel, Antonin Houska írta:
>
>> On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote:
>>>
>>> Hi,
>>>
>>> I am reviewing your patch.
>>
>> Thanks. New version attached.
>
>
> I have reviewed and tested it and m
Hi,
2013-12-05 15:36 keltezéssel, Antonin Houska írta:
On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thanks. New version attached.
I have reviewed and tested it and marked it as ready for committer.
Best regards,
Zoltán Böszörményi
--
---
On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> I am reviewing your patch.
Thanks. New version attached.
>
> * Does it follow the project coding guidelines?
>
> Yes. A nitpicking: this else branch below might need brackets
> because there is also a comment in that branch:
>
> +
Hi,
I am reviewing your patch.
2013-10-10 15:32 keltezéssel, Antonin Houska írta:
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 pat
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 s
On Tue, Sep 3, 2013 at 8:35 AM, Antonin Houska wrote:
> On 07/24/2013 09:20 AM, Antonin Houska wrote:
>> Hello,
>> the purpose of this patch is to limit impact of pg_backup on running
>> server.
>
> Attached is a new version. Server-side implementation this time.
>
> Antonin Houska (Tony)
There s
On 2013-09-03 12:56:53 -0400, Alvaro Herrera wrote:
> Antonin Houska wrote:
>
> > +
> > +Suffixes k (kilobytes) and m
> > +(megabytes) are accepted. For example: 10m
> > +
>
> "m" is for meters, or milli. Please use "M" here.
Shouldn't it be MB? Consistent with GUC
On 09/03/2013 06:56 PM, Alvaro Herrera wrote:
>> +/*
>> + * Only the following suffixes are allowed. It's not
>> too useful to
>> + * restrict the rate to gigabytes: such a rate will
>> probably bring
>> + * signific
Antonin Houska wrote:
> +
> +Suffixes k (kilobytes) and m
> +(megabytes) are accepted. For example: 10m
> +
"m" is for meters, or milli. Please use "M" here.
> +static uint32
> +parse_max_rate(char *src)
> +{
> + int factor;
> + char
Hi,
On 2013-09-03 14:35:18 +0200, Antonin Houska wrote:
> + /*
> + * THROTTLING_SAMPLE_MIN / MAX_RATE_LOWER (in seconds) should
> be the
> + * longest possible time to sleep.
> + */
> + pg_usleep((long) sleep);
> + else
> +
> +
On 07/24/2013 09:20 AM, Antonin Houska wrote:
> Hello,
> the purpose of this patch is to limit impact of pg_backup on running
> server.
Attached is a new version. Server-side implementation this time.
Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_b
On 8/27/13 7:58 AM, Robert Haas wrote:
We have a *general* need to be able to throttle server-side resource
utilization, particularly I/O. This is a problem not only for
pg_basebackup, but for COPY, CLUSTER, VACUUM, and even things like
UPDATE. Of all of those, the only one for which we curren
On 08/27/2013 01:58 PM, Robert Haas wrote:
> On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
> wrote:
>> Throttling in the client seems much better to me. TCP is designed to handle
>> a slow client.
>
> Other people have already offered some good points in this area, but
> let me just add one
On Tue, Aug 27, 2013 at 12:58 PM, Robert Haas wrote:
> On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
> wrote:
> > Throttling in the client seems much better to me. TCP is designed to
> handle
> > a slow client.
>
> Other people have already offered some good points in this area, but
> let
On Tue, Aug 20, 2013 at 2:37 AM, Heikki Linnakangas
wrote:
> Throttling in the client seems much better to me. TCP is designed to handle
> a slow client.
Other people have already offered some good points in this area, but
let me just add one thought that I don't think has been mentioned yet.
We
On 08/27/2013 01:56 AM, Antonin Houska wrote:
> 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 ov
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 reasona
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
>>
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
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 rever
On Wed, 2013-07-24 at 09:20 +0200, Antonin Houska wrote:
> the purpose of this patch is to limit impact of pg_backup on running
> server. Feedback is appreciated.
Please replace the tabs in the SGML files with spaces.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
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 ma
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 m
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
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, Ant
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
2013-08-20 08:37 keltezéssel, Heikki Linnakangas írta:
On 19.08.2013 21:15, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
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
buf
On 19.08.2013 21:15, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
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 conside
2013-08-19 21:11 keltezéssel, Andres Freund írta:
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 serve
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.
> >B
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
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 laten
2013-07-31 22:50 keltezéssel, Antonin Houska írta:
On 07/31/2013 07:13 AM, Gibheer wrote:
Hi,
That is a really nice feature.
I don't pretend it's my idea, I just coded it. My boss proposed the feature as
such :-)
I took a first look at your patch and some empty lines you added (e.g. line 60
On Wed, 31 Jul 2013 22:50:19 +0200
Antonin Houska wrote:
> On 07/31/2013 07:13 AM, Gibheer wrote:
> > Hi,
> >
> > That is a really nice feature.
> I don't pretend it's my idea, I just coded it. My boss proposed the
> feature as such :-)
> > I took a first look at your patch and some empty lines
On 07/31/2013 07:13 AM, Gibheer wrote:
Hi,
That is a really nice feature.
I don't pretend it's my idea, I just coded it. My boss proposed the
feature as such :-)
I took a first look at your patch and some empty lines you added (e.g. line 60
your patch). Can you remove
them?
Sure, will do in
Gibheer escribió:
> Why did you move localGetCurrentTimestamp() into streamutil.c? Is
> sys/time.h still needed in receivelog.c after the move?
I think we should have GetCurrentTimestamp() in src/common; there are
way too many copies of that functionality now. I looked into this
awhile back, but
On Wed, 24 Jul 2013 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.
>
> // Antonin Houska (Tony)
Hi,
That is a really nice feature. I took a first look at your patch and
some empty lines yo
On Wed, Jul 24, 2013 at 4:20 PM, Antonin Houska
wrote:
> Hello,
> the purpose of this patch is to limit impact of pg_backup on running server.
> Feedback is appreciated.
Interesting. Please add this patch to the next commitfeat.
https://commitfest.postgresql.org/action/commitfest_view?id=19
Rega
49 matches
Mail list logo
