Hello Tom & Michaël,
I think this patch should be rejected.
+1 for rejection [...]
The noes have it!
Note that the motivation was really symmetric completion:
fabien=# \echo :VERSION_NAME
11devel
fabien=# \echo :VERSION_NUM
11
fabien=# \echo :VERSION
PostgreSQL 11devel on x86_64-
Hello Tom,
ISTM That there is still at least one strange cast:
+static const char **LWLockTrancheArray = NULL;
+ LWLockTrancheArray = (const char **) // twice
These are not cases of "cheating". This is just the return value of a
memory allocation function being cast from void
Hello,
Maybe I'm missing something, but it looks that it could be made to work
without adding another boolean.
The tuples only cannot be disabled, because then other parts print number
of rows
postgres=# \pset format unaligned
Output format is unaligned.
postgres=# select 10 as a, 20 as b;
Would it make sense that the function returns "const void *", i.e. the cast
is not on the const part but on the pointer type part?
Or maybe you do not really need a cast, the following code does not
generate any warning when compiled with clang & gcc.
#include
// const void * would be o
ISTM That there is still at least one strange cast:
+static const char **LWLockTrancheArray = NULL;
+ LWLockTrancheArray = (const char **) // twice
These are not cases of "cheating". This is just the return value of a
memory allocation function being cast from void * to the
ISTM that you can remove "force_column_header" and just set "tuple_only"
to what you need, that is you do not need to change anything in function
"print_unaligned_text".
Last point is not possible - I would not to break original tuple only mode.
Hmmm... I do not understand. I can see only on
Hello Pavel,
I hope so I fixed all mentioned issues.
Patch applies with a warning:
> git apply ~/psql-graw-2.patch
/home/fabien/psql-graw-2.patch:192: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Otherwise it compiles. "make check" ok. doc gen ok.
Two spurious empty
I don't want to go too deep into it, but you get stuff like this:
Select pow(2.0, -3)::text = pow(2, -3)::text;
Sure. It does so with any overloaded operator or function:
fabien=# SELECT (2.0 + 3)::TEXT = (2 + 3)::TEXT; # f
Patch applies, make check ok in pgbench, doc gen ok.
ipow code i
Hello,
Sorry for the confusion, I wasn't aware that SQL pow changed types
depending on the input value.
Indeed, this is quite strange...
fabien=# SELECT i, POW(2, i) FROM generate_series(-2, 2) AS i;
-2 | 0.25
-1 | 0.5
0 | 1
1 | 2
2 | 4
I've modified the function to matc
Hello Raúl,
I've fixed the documentation and added an ipow function that handles both
positive and negative ints, having 0^0 == 1 and 0^(negative) == PG_INT64_MAX
since that's what my glibc math.h pow() is returning.
From the comment:
* For exp < 0 return 0 except when the base is 1 or -1
Just leave it as char*. If you change the endptr argument you're going to
force every call site to change their return variable, and some of them
would end up having to cast away the const on their end.
OK, here is an updated patch with the controversial bits removed.
I'm in general favor i
Hello Raúl,
Sorry about the patch. Attaching it now so it can be considered as
submitted.
There is a typo in the XML doc:
1024.0/
Please check that the documentation compiles.
I'm at odds with having the integer version rely on a double pow(), even
if it works. I think that there
Hello Pavel,
Here is a v13, which is just a rebase after the documentation xml-ization.
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
I am looking to this patch.
Not sure if "cset" is best name - maybe "eset" .. like embeded set?
I used c
[ pgbench-enum-meta-2.patch ]
Pushed with some trivial cosmetic adjustments (pgindent changed
it more than I did).
Ok. Thanks.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Hello,
Could you rebase the v11 patch?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Updated version attached.
. Here is the patch. Sorry for the noise.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 5d8a01c..6bd3e52 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -373,11 +373,21 @@ typedef enum QueryMode
static Q
The only thing I'm not quite sure about is a comment "which meta command
...". Maybe it's better to write it without question word, something
like "meta command identifier..."?
Ok. I agree.
Updated version attached. I also added a const on a function parameter.
Just a note about the motivat
Hello Michaël,
I'm fine with having pow in pgbench.
I am adding as well Fabien in CC who worked in getting the internal
function infrastructure in the shape it is now (waaay better) with
commit 86c43f4.
It might be even better if https://commitfest.postgresql.org/15/985/,
which has been aro
Here is a v12.
Here is a v13, which is just a rebase after the documentation xml-ization.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index e509e6c..44e8896 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -818,6 +818,5
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Here is a v14, which is just a rebase after the documentation xml-ization.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index e509e6c..1f55967 100644
--- a/doc/sr
The patch needs a rebase in the documentation because of the xml-ilization
of the sgml doc.
Thank you for the notification! Attached rebased patch.
Ok. The new version works for me.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hello Masahiko-san,
Attached the updated version patch.
Applies, compiles, make check & tap test ok, doc is fine.
All is well for me: the feature is useful, code is simple and clean, it is
easy to invoke, easy to extend as well, which I'm planning to do once it gets
in.
I switched the pa
The make dependencies ensure that the header file is regenerated on each
build with a phony target, and the C file is thus recompiled and linked into
the executables on each build. It means that all executables are linked on
each rebuild, even if not necessary, though.
That'd be quite painful,
Hello Robert,
Mmph. I understand the desire to identify the exact commit used for a
build somehow, but something whose output depends on whether or not I
left a branch lying around locally doesn't seem that great.
Indeed, the branch/tag search might have a little strange behavior.
Probably
Hello Tom,
I've seen issues with a number of tools. The one I can remember most
clearly is check_postgres.pl . Nobody's going to argue that this is
pretty code, but last time I tested (9.4-era, admittedly) it exploded
messily with extra-version.
FWIW, Salesforce tried to do something similar
This patch enables building pgbench to use ppoll() instead of select()
to allow for more than (FD_SETSIZE - 10) connections. As implemented,
when using ppoll(), the only connection limitation is system resources.
One based on 'master' which can also apply to REL_10_STABLE.
/home/fabien/pgbe
Hello,
Fabien COELHO writes:
I wanted to know which version it was, and "11devel" is kind of imprecise.
...
ISTM that extending the version name with the commit id and or date in
some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it.
configure
Hello,
I use postgres "11devel" packages kindly distributed on
"apt.postgresql.org" and recompiled every few hours.
I wanted to know which version it was, and "11devel" is kind of imprecise.
Ok, there is a hint in the deb package name:
11~~devel~20170930.2214-1~87.git2632bcc.pgdg16.
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.
Committed and back-patched to v10. I have to say I'm kind of
surprised that the comment removed by this patch got committed in the
first place. It's got a ??? in it and isn't very grammatical either.
ISTM that I reviewed the initial patch.
AFAICR I agreed with the comment that whether it wa
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
Hello Pavel,
1. It is placed on my personal repository on GitHub. It is far to perfect
from security, from substitutability perspective.
Any ideas?
Ask to have a copy on git.postgresql.org?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
- Run pgbench -c 10 -T 100
- Stop postgres with -m immediate
That is a strange test to run, but it would be better if the behavior was
not that one.
Well, I think it's a very legitimate test, not for testing performance, but
testing crash recovery and I use it very often.
Ok, interesting.
The commit that introduced this code is 12788ae49e1933f463bc. So I amn
copying Heikki.
AFAICR the commit was mostly a heavy restructuring of previous unmaintainable
spaghetti code. I'm not sure the problem was not there before under one form
or another.
I agree that it should error out & s
While running some tests, I encountered a situation where pgbench gets
stuck in an infinite loop, consuming 100% cpu. The setup was:
- Start postgres server from the master branch
- Initialise pgbench
- Run pgbench -c 10 -T 100
- Stop postgres with -m immediate
That is a strange test to run,
Hello Again,
Two patches attached.
One based on REL9_6_STABLE.
I'd be surprise that there would be a backport unless there is a bug, so
this one might not be useful.
One based on 'master' which can also apply to REL_10_STABLE.
Could you add your patches to the next CF?
--
Fabien.
--
Hello Doug,
total time: 316.03 s (insert 161.60 s, commit 0.64 s, vacuum 60.77 s, index
93.01 s)
Definitely interesting.
There is a "ready for committers" patch in the CF which extensively rework
the initialization: it becomes customizable, and this approach may not
work as is after that.
Hello,
This should be fixed for PG10, so if you have any feedback on the
design, please let me know soon.
Works for me on head against a 9.6 server, which is good.
My 0.02 €:
\d+ does not show more.
Maybe Type, Min, Max, Inc & Cycles are enough for \d?
The next/future or last/previous val
Hello Tom,
Well, I think it's mostly about valgrind making everything really slow. Since
we have seen some passes from skink recently, perhaps there was also a
component of more-load-on-the-machine-than-usual. But in the end this is
just evidence for my point that regression tests have to
Hello Tom,
# progress: 2.6 s, 6.9 tps, lat 0.000 ms stddev 0.000, lag 0.000 ms, 18 skipped
# progress: 3.0 s, 0.0 tps, lat -nan ms stddev -nan, lag -nan ms, 0 skipped
# progress: 4.0 s, 1.0 tps, lat 2682.730 ms stddev 0.000, lag 985.509 ms, 0
skipped
(BTW, the "-nan" bits suggest an actual p
Hello Gerdan,
This is an internal address that should not be exposed:
postgresql@coelho.net
I'm unsure why it gets substituted by the "commitfest application"...
When i try apply this patch he failed with a following messenger:
It just worked for me on head with
git checkou
Minor code enhancement.
While having a look at adding if/elif/else/endif to pgbench, and given the
current gset/cset added meta commands in cf queue, it occured to me that
repeated string comparisons to check for the various meta commands is
neither efficient nor readable. Use an enum instead
[...] After another week of buildfarm runs, we have a few more cases of
3 rows of output, and none of more than 3 or less than 1. So I went
ahead and pushed your patch. I'm still suspicious of these results, but
we might as well try to make the buildfarm green pending investigation
of how t
Hello Masahiko-san,
ISTM that you probably intended "\(.*\)" (actual parenthesis) instead of
"(.*)" (memorization) in the data generation message check.
Thank you, fixed it.
Otherwise all is well for me.
Attached the updated version patch.
Applies, compiles, make check & tap test ok, d
Correct Fabien. I have already removed myself as a reviewer. Thanks.
As you wish!
Thanks for the feedback, which I understood as "works for me".
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Hello Robins,
I was able to test the functionality (which seemed to work fine) and fed in
my comment to assist anyone else reviewing this patch (and intentionally
let it's state as 'Needs Review').
While trying to provide my feedback, on hindsight I should have been more
detailed about what I
Hello Masahiko-san,
v14 applies, compiles and works. TAP tests provide good coverage.
ISTM that you probably intended "\(.*\)" (actual parenthesis) instead of
"(.*)" (memorization) in the data generation message check.
Otherwise all is well for me.
--
Fabien.
--
Sent via pgsql-hackers mai
Hello Robins,
Thanks for the review.
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Where ?
Spec compliant: not tested
Documentation:tested, failed
Where ? I just
Hello Masahiko-san,
Attached the latest version patch incorporated the tap tests.
Please review it.
Patch applies, compilation & make check ok.
Tests are simple and provide good coverage of new functionalities.
I would suggest to add '--unlogged-tables' so speedup the tests a little.
Comme
Hello,
Personnally I'm fine with a pager, so vertical spacing is fine. I just do
not like paging horizontally.
-1 [...]
If I was going to try and read it like a book I'd want the extra
white-space to make doing so easier (white-space gives the eye a breather
when done with a particular co
Hello Tom,
Probably it needs some rebase after Tom committed result status variables.
As it is a style thing, ISTM that the patch is ready if most people agree
that it is better this way and there is no strong veto against.
FWIW, I think it's a bad idea. We already nearly-doubled the vert
I have a serious, serious dislike for tests that seem to work until
they're run on a heavily loaded machine.
I'm not that sure the error message was because of that.
No, this particular failure (probably) wasn't. But now that I've realized
that this test case is timing-sensitive, I'm worri
One thing we could think about if this seems too high is to drop
ROW_COUNT. I'm unconvinced that it has a real use-case, and it seems
to be taking more than its share of the work in non-error cases, because
it turns out that PQcmdTuples() is not an amazingly cheap function.
I do think that a
Hello Tom,
I put back SetResultVariables function which is called twice, for SQL
queries and the new descriptions. It worked out of the box with DECLARE
which is just another SQL statement, so maybe I did not understood the
cursor issue you were signaling...
No, I was concerned about ExecQuer
Finally, as vertical scrolling is mandatory, I would be fine with
skipping lines with entries for readability, but it is just a matter of
taste and I expect there should be half a dozen different opinions on
the matter of formatting.
FWIW, +1 to extra lines from me - I find it way more readabl
Well, if we provided a different SQLSTATE for each qualitatively
different type of libpq error, that might well be useful enough to
justify some risk of application breakage. But replacing a constant
string that we've had for ~15 years with a different constraint string
isn't doing anything abo
I have a serious, serious dislike for tests that seem to work until
they're run on a heavily loaded machine.
I'm not that sure the error message was because of that. ISTM that it was
rather finding 3 seconds in two because it started just at the right time,
or maybe because of slowness induc
Apparently, one of the threads ran 3 transactions where the test script
expects it to run at most 2. Is this a pgbench bug, or is the test
being overoptimistic about how exact the "-T 2" cutoff is?
Probably both? It seems that cutting off on time is not a precise science,
so I suggest to acc
Hello Tom,
Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
situation where libpq did not report an error?
Meh. If we're going to do that I think it might be better to hack
libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE)
to always return som
francolin just showed a non-reproducing failure in the new pgbench tests:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2017-09-12%2014%3A00%3A02
not ok 211 - transaction count for 001_pgbench_log_1.31583 (3)
# Failed test 'transaction count for 001_pgbench_log_1.3
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
I think you're overly optimistic to believe that every failure will
have a SQLSTATE; I don't think that's true for libpq-reported errors,
such as connection loss.
Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
situation where libpq did not report an error?
Meh. If
Hello Tom,
Hm. Looking closer at this, I see that it doesn't work so well after all
to put the variable-setting code in ProcessResult:
that fails to cover the ExecQueryUsingCursor code path.
Ok, I'll investigate this path.
And it also fails to cover DescribeQuery, which arguably should set
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
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Summary of patch contents: [...]
1. there are no any problem with compilation, patching
2. all tests passed
3. doc is ok
I'll mark this patch as ready for commiter
Ok. Thanks for the reviews.
--
Fa
Hello Pavel,
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Summary of patch contents:
This patch extends pgbench expressions syntax while keeping
compatibility with SQL expressions.
It adds support for NULL and BOOLEAN, as well as assorted log
Hello,
Please find attached "blind" additional fixes for Windows & AIX.
- more nan/inf variants
- different message on non existing user
- illegal vs unrecognized options
I suspect that $windows_os is not true on "bowerbird", in order to fix it
the value of "$Config{osname}" is needed...
Here is a v12.
There is no changes in the code or documentation, only TAP tests are
added.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f5db8d1..9ad82d4 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -818,6 +818,
Hello Tom,
Pushed, with some minor fooling with comments and after running it
through perltidy. (I have no opinions about Perl code formatting,
but perltidy does ...)
Why not. I do not like the result much, but it homogeneity is not a bad
thing.
The only substantive change I made was to
Hello,
PSQL_HISTORY alternative location for the command history file
I would prefer to revert to that more compact 9.6-formatting.
There was a problem with line width .. its hard to respect 80 chars
Yes.
Scrolling in two dimensions because it does not fit either way is not too
p
Hello Pavel,
I checked performance - the most fast queries are execution of simple
prepared statement
prepare x as select 1;
-- 100 x
execute x;
execute x;
execute x;
execute x;
## patched
[pavel@nemesis postgresql]$ time psql -At -1 postgres -f ~/xxx.sql >
/dev/null
real 0m44,887s
user
Very very minor comments that I should have noticed before, sorry for this
additional round trip.
Thank you for the dedicated review!
I'm someone at times pigheaded, I think in the good sense if it is
possible, and I like to finish what I start:-)
Patch applies, compiles, works, everythin
you can't do this sort of thing:
-psql_error("The server (version %s) does not support editing function
source.\n",
+psql_error("The server (version %s) does not support editing
%s.\n",
formatPGVersionNumber(pset.sversion, false,
-
Thus short, simple but meaningful examples which show how to do something
useful with all that in the documentation may help people take advantage
of these new features.
I don't have an objection to providing an example. I wasn't terribly
impressed with Simon's version, but maybe we can do be
Hello,
* Clarification that this will work for current AND past server versions
The short answer is it works. I do not think we need a longer answer.
To have something operational you have to know quite a bit of psql
details (:-substitutions, backslash command logic, gset, if, quit...).
T
Seeing it as is, it calls for having "SERVER_VERSION" as well, but I'm not
sure of the better way to get it. I tried with "SELECT VERSION() AS
SERVER_VERSION \gset" but varnames are lowerized.
The problem there is you can't get version() without an extra round trip
to the server --- and an ext
Here is a version 6.
Small v7 update, sorry for the noise.
Add testing the initial state of all variables.
Fix typos in a comment in tests.
Fix the documentation wrt the current implementation behavior.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
Hello Tom,
Here is a version 6.
A few thoughts about this patch:
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x
Applies, compiles, works for me.
Very very minor comments that I should have noticed before, sorry for this
additional round trip.
In the help line, move -I just after -i, to put short options in
alphabetical and decreasing importance order. On this line, also add the
information about the
Hello Alik,
Applies, compiles, works for me.
Some minor comments and suggestions.
Two typos:
- "usinng" -> "using"
- "a rejection method used" -> "a rejection method is used"
I'm not sure of "least_recently_used_i", this naming style is not used in
pgbench. "least_recently_used" would be o
* It might be better if SQLSTATE and ERROR_MESSAGE were left
unchanged by a non-error query.
Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE
maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE
& ERROR_MESSAGE reflect the last command, and ERROR is
Huh? The variable will be set in any case. It should be correct for any
server version we might find in the wild --- so far as I can tell from the
commit history, every version supporting FE/BE protocol version 3 has sent
server_version at connection start. With a pre-7.4 server, it looks lik
Hello Simon,
Does raise the further question of how psql behaves when we connect to
a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set.
How does this
\if SERVER_VERSION_NUM < x
The if does not have expressions (yet), it just handles TRUE/ON/1 and
FALSE/0/OFF.
Do we need
Hello Tom,
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x' construct in pl/pgsql, or the
sqlstate attribute o
This is good. Please can we backpatch these are far as they will go
(easily)? There is very little risk in doing so and significant
benefits in being able to rely on scripts that know about versions.
Hm. I think it would be a fine idea to push this change into v10,
so that all psql versions
[ psql-version-num-8.patch ]
Pushed with some minor additional fiddling.
Ok, Thanks. I also noticed the reformating.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sorry, I don't follow that. You meant I should add a newline before
pg_realloc()? That is,
+initialize_cmds =
+(char *) pg_realloc(initialize_cmds,
+sizeof(char) * n_cmds + 1);
Yes. Or maybe my
Attached the latest patch. Please review it.
Patch applies and compiles cleanly.
Three very minor points:
Typo added in the documentation: ".Each" -> ". Each".
In "case 8:" there is a very long line which lacks a newline before
pg_realloc second argument.
I think that the check should si
Hello Tom,
sub pgbench($)
My concern is basically about maintaining coding style consistency.
Yes, I'm fine with that. I have removed it in the v12 patch.
reasons why it's not like that already. I do have to say that many of
the examples I've seen look more like line noise than reada
Anyway, done with the addition of a "chomp" parameter, leaving only the
TAP test changes to consider.
Ok, thanks.
I'll set the CF entry back to "waiting on author" pending your
revisions of those.
See attached.
Removed scalar/array ref hack, plenty [] added everywhere to match.
Removed p
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
I think we should go with Daniel's idea for all three parts.
I'm okay with that, although probably it should be an independent patch.
In the documentation, I do not think that both SERVER_VERSION_NAME and
_NUM (or whatever their chosen name) deserve two independent explanations
with heavy re
Hello Tom,
As for included bug fixes, I can do separate patches, but I think that it
is enough to first commit the pgbench files and then the tap-test files,
in that order. I'll see what committers say.
Starting to look at this. I concur that the bug fixes ought to be
committed separately, b
Hello Tom,
So I thought we were done bikeshedding the variable names for this
feature, but as I was reviewing the patch with intent to commit,
I noticed you hadn't updated helpVariables() to mention them.
Indeed.
Possibly you missed this because it doesn't mention VERSION either,
but that d
Looks good to me. I have marked the patch status as "Ready for
committer".
LGTM too. Pushed with a minor adjustment to make parseVariable()
have exactly the same test as valid_variable_name().
\set ありがとうございました 1
\set 谢谢 2
\set dankeschön 3
:-)
--
Fabien.
--
Sent via pgsql-hackers maili
Hello Masahiko-san,
Currently TRUNCATE pgbench_accounts command is executed within a
transaction started immediately before it. If we move it out of the
transaction, the table data will be truncated even if the copying data
failed. Maybe we can do TRUNCATE pgbench_accounts, pgbench_history
inst
I'm wondering whether this truncation should be yet another available
command? Hmmm... maybe not.
Currently TRUNCATE pgbench_accounts command is executed within a
transaction started immediately before it. If we move it out of the
transaction, the table data will be truncated even if the copyi
Hello Masahiko-san,
Patch applies and compiles.
One bug found, and some minor points again. Sorry for this hopefully last
iteration... I'm kind of an iterative person...
I've generated the doc to look a it.
Short option "-I" does not use a "=", it should be "-I
custom_init_commands".
Als
Hello Nikolay,
Thanks for the review!
As for function names, committers can have their say. I'm somehow not
dissatisfied with the current version, but I also agree with you that they
are imperfect.
As for included bug fixes, I can do separate patches, but I think that it
is enough to first
Hello Masahiko-san,
[...] Personally I prefer "t" for table creation because "c" for create
is a generic word. We might want to have another initialization command
that creates something.
Ok, good point.
About the patch: applies, compiles, works for me. A few minor comments.
While re-read
1 - 100 of 1589 matches
Mail list logo
