Thank you, pushed
Fabien COELHO wrote:
Patch isn't applyed cleanly anymore.
Indeed. Here is a rebase. All pgbench patches conflict about test cases.
Patch v12, yet another rebase.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Patch isn't applyed cleanly anymore.
Indeed. Here is a rebase. All pgbench patches conflict about test cases.
Patch v12, yet another rebase.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index d52d324..41d9030 100644
--- a/doc/src/sgml/ref/pgbench.sgml
Patch isn't applyed cleanly anymore.
Indeed. Here is a rebase. All pgbench patches conflict about test cases.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f07ddf1..e4582bf 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.s
Patch isn't applyed cleanly anymore.
Fabien COELHO wrote:
But now the documentation is back to its original state of silence on
what base or how many bases might be allowed. Could it just say
"or an unsigned decimal integer value"? Then no one will wonder.
Done in the attached.
Thanks for t
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
This is a simple patch, includes documentation, includes and pass
But now the documentation is back to its original state of silence on
what base or how many bases might be allowed. Could it just say
"or an unsigned decimal integer value"? Then no one will wonder.
Done in the attached.
Thanks for the reviews.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench
I'm sorry, I must have missed your reply on the 5th somehow.
On 03/05/18 07:01, Fabien COELHO wrote:
> I must admit that I'm not too happy with the result as well, so I dropped
> the octal/hexadecimal parsing.
That seems perfectly reasonable to me; perfectly adequate to accept only
one base.
But
Hello Chapman,
Here is v9.
It needs s/explicitely/explicitly/ in the docs.
Done.
The parsing of the seed involves matters of taste, I guess: if it were a
signed int, then sscanf's built-in %i would do everything those three
explicit hex/octal/decimal branches do, but there's no unsigned v
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
The patch 8 works and addresses the things I noticed earlier.
It
Fabien COELHO writes:
>> Hm ... so I tried to replicate this problem, and failed to: the log files
>> get made under the VPATH build directory, as desired, even without this
>> patch. Am I doing something wrong, or is this platform-dependent somehow?
> As I recall, it indeed works if the source
Hello Tom,
Fabien COELHO writes:
This is a simple patch that does what it says on the tin. I ran into
trouble with the pgbench TAP test *even before applying the patch*, but
only because I was doing a VPATH build as a user without 'write'
on the source tree (001_pgbench_with_server.pl tried t
Fabien COELHO writes:
>> This is a simple patch that does what it says on the tin. I ran into
>> trouble with the pgbench TAP test *even before applying the patch*, but
>> only because I was doing a VPATH build as a user without 'write'
>> on the source tree (001_pgbench_with_server.pl tried to ma
Here is a rebase, plus some more changes:
I have improved the error message to tell from where the value was
provided.
I have removed the test to the exact values produced from the expression
test run.
I have added a test which run from the same seed value several times
and checks that th
Here is a rebase, plus some more changes:
I have improved the error message to tell from where the value was provided.
I have removed the test to the exact values produced from the expression test
run.
I have added a test which run from the same seed value several times
and checks that the
Here is a rebase, plus some more changes:
I have improved the error message to tell from where the value was
provided.
I have removed the test to the exact values produced from the expression
test run.
I have added a test which run from the same seed value several times
and checks that the
This is a simple patch that does what it says on the tin. I ran into
trouble with the pgbench TAP test *even before applying the patch*, but
only because I was doing a VPATH build as a user without 'write'
on the source tree (001_pgbench_with_server.pl tried to make pgbench
create log files ther
Hello Chapman,
Thanks for the review,
The tests assume that stdlib random/srandom behavior is standard thus
deterministic between platform.
Is the behavior of srandom() and the system generator really so precisely
specified that seed 5432 will produce the same values hardcoded in the
tests o
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Initial review is the message this is in reply to.
The new status of
On 01/02/18 05:57, Fabien COELHO wrote:
>> Here is a new version which output use used seed when a seed is
>> explicitely set with an option or from the environment.
This is a simple patch that does what it says on the tin. I ran into
trouble with the pgbench TAP test *even before applying the pa
Here is a new version which output use used seed when a seed is explicitely
set with an option or from the environment.
It is even better without xml typos, with simpler coding and the doc in
the right place... Sorry for the noise.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/
Hello Alvaro,
I revive this patch because controlling the seed is useful for tap testing
pgbench.
The output should include the random seed used, whether it was passed
with --random-seed, environment variable or randomly determined. That
way, the user that later wants to verify why a parti
21 matches
Mail list logo
