On 09/29/2017 08:43 PM, Fabien COELHO wrote:
reality. So I don't know if this needs backpatching or not. But it
should be fixed for v10, as there it becomes a demonstrably live issue.
Yes.
Patch looks good to me, so committed to master and v10. Thanks!
- Heikki
--
Sent via pgsql-hackers
Hello Robert,
ISTM that this bug exists since rate was introduced, so shame on me and
back-patching should be needed.
I took a look at this and found that the proposed patch applies
cleanly all the way back to 9.5, but the regression is reported to
have begun with a commit that starts in v10.
On Mon, Sep 11, 2017 at 4:49 AM, Fabien COELHO wrote:
> Ok, the problem was a little bit more trivial than I thought.
>
> The issue is that under a low rate there may be no transaction in progress,
> however the wait procedure was relying on select's timeout. If nothing is
> active there is nothin
reality. So I don't know if this needs backpatching or not. But it
should be fixed for v10, as there it becomes a demonstrably live issue.
Yes.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Mon, Sep 11, 2017 at 6:27 PM, Fabien COELHO wrote:
>
> Hello Jeff,
>
> Shouldn't we use pg_usleep to ensure portability? it is defined for
>> front-end code. But it returns void, so the error check will have to be
>> changed.
>>
>
> Attached v3 with pg_usleep called instead.
>
> I didn't see
On Tue, Sep 12, 2017 at 03:27:13AM +0200, Fabien COELHO wrote:
> >Shouldn't we use pg_usleep to ensure portability? it is defined for
> >front-end code. But it returns void, so the error check will have to be
> >changed.
>
> Attached v3 with pg_usleep called instead.
>
> >I didn't see the probl
Hello Jeff,
Shouldn't we use pg_usleep to ensure portability? it is defined for
front-end code. But it returns void, so the error check will have to be
changed.
Attached v3 with pg_usleep called instead.
I didn't see the problem before the commit I originally indicated , so I
don't think
On Mon, Sep 11, 2017 at 1:49 AM, Fabien COELHO wrote:
>
> Hello Jeff,
>
> Ok, the problem was a little bit more trivial than I thought.
>
> The issue is that under a low rate there may be no transaction in
> progress, however the wait procedure was relying on select's timeout. If
> nothing is act
Hello Jeff,
Ok, the problem was a little bit more trivial than I thought.
The issue is that under a low rate there may be no transaction in
progress, however the wait procedure was relying on select's timeout. If
nothing is active there is nothing to wait for, thus it was an active loop
in t
On Mon, Sep 4, 2017 at 1:56 PM, Fabien COELHO wrote:
>
> Hello Jeff,
>
> I have fixed a bug introduced in the patch by changing && by || in the
(min_sec > 0 && maxsock != -1) condition which was inducing errors with
multi-threads & clients...
>>>
> Since this commit (12788ae49e1933
Hello Jeff,
I have fixed a bug introduced in the patch by changing && by || in the
(min_sec > 0 && maxsock != -1) condition which was inducing errors with
multi-threads & clients...
Since this commit (12788ae49e1933f463bc5), if I use the --rate to throttle
the transaction rate, it does get t
On Mon, Sep 26, 2016 at 1:01 AM, Heikki Linnakangas wrote:
> On 09/24/2016 12:45 PM, Fabien COELHO wrote:
>
>>
>> Attached are some small changes to your version:
>>
>> I have added the sleep_until fix.
>>
>> I have fixed a bug introduced in the patch by changing && by || in the
>> (min_sec > 0 &
On 09/24/2016 12:45 PM, Fabien COELHO wrote:
Although I cannot be absolutely sure that the refactoring does not
introduce any new bug, I'm convinced that it will be much easier to find
them:-)
:-)
Attached are some small changes to your version:
I have added the sleep_until fix.
I have fixe
Hello Heikki,
Yeah, it really is quite a mess. I tried to review your patch, and I think
it's correct, but I couldn't totally convince myself, because of the existing
messiness of the logic. So I bit the bullet and started refactoring.
I came up with the attached. It refactors the logic in d
Hello Heikki,
Yeah, it really is quite a mess. I tried to review your patch, and I think
it's correct, but I couldn't totally convince myself, because of the existing
messiness of the logic.
Alas:-(
So I bit the bullet and started refactoring.
Wow!
I came up with the attached. It refact
The attached patch provides a solution which ensures the return in the right
condition and after the stat collection. The code structure requires another
ugly boolean to proceed so as to preserve doing the reconnection between the
decision that the return must be done and the place where it ca
Hello Tom,
Ok. Here is an updated version, with a better suffix and a simplified
comment.
Doesn't this break the handling of latency calculations, or at least make
the results completely different for the last metacommand than what they
would be for a non-last command? It looks like it needs
Fabien COELHO writes:
> Ok. Here is an updated version, with a better suffix and a simplified
> comment.
Doesn't this break the handling of latency calculations, or at least make
the results completely different for the last metacommand than what they
would be for a non-last command? It looks l
Hello Michaƫl,
You may want to name your patches with .patch or .diff. Using .sql is
disturbing style :)
Indeed! :-)
Indeed, not reporting the progress back to the client in the case of a
script with only meta commands is non-intuitive.
This looks good to me. I'd just rewrite the comment b
On Sat, Jul 9, 2016 at 4:09 PM, Fabien COELHO wrote:
>
> While testing meta-command pgbench only scripts, I noticed that there is an
> infinite loop in threadRun, which means that other tasks such as reporting
> progress do not get a chance.
>
> The attached patch breaks this loop by always return
While testing meta-command pgbench only scripts, I noticed that there is
an infinite loop in threadRun, which means that other tasks such as
reporting progress do not get a chance.
The attached patch breaks this loop by always returning at the end of a
script.
On "pgbench -T 3 -P 1 -f noop
21 matches
Mail list logo