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
110000
fabien=# \echo :VERSION
PostgreSQL 11devel on x8
onst char * msg = (const char *) msg_func();
does not really make full sense to me, and moreover the compiler does not
complain without the const.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
thin the header or within the footer... Maybe the whole
topt logic should be reviewed, but that is not the point of this patch.
So I switched the patch to "ready for committer".
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
her like more precise declarations.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
make sense that the function returns "const void *", i.e. the
cast is not on the const part but on the pointer type part?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. Looking at the detailed code in that function, probably you
need to set start_table to on when headers are needed and stop_table to
off for the raw mode anyway?
Maybe I'm missing something, but it looks that it could be made to work
without adding another boolean.
--
Fabien.
--
Sent via pgsql-hacke
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.
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
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
s 1 or -1
I think that it should do what POW does in psql, i.e.:
fabien=# SELECT POW(2, -2); # 0.25
that is if exp < 0 the double version should be used, it should
not return 0.
Basically the idea is that the pgbench client-side version should behave
the same as the SQL version.
--
Fabien.
-
ot
really justified?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
se *= base;
}
return result;
}
The integer version should be when x & y are integers *AND* y >= 0.
if y is a negative integer, the double version should be used.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
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
[ 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
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
e "\if" patch, some day, after this one get committed, if it gets
committed.
The new status of this patch is: Ready for Committer
Thanks for the review.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
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
---
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
ched the patch to "Ready for Committers". No doubt they will have their
own opinions about it. Let's wait and see.
The patch needs a rebase in the documentation because of the xml-ilization
of the sgml doc.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
version and it would not change depending on updated libs,
and so that we always know (or should know) what actual version is
running.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
you would be more happy with just the commit (--always) & knowing
that it was changed (--dirty).
sh> git describe --always --dirty
b81eba6
sh> vi README
# edit
sh> git describe --always --dirty
b81eba6-dirty
--
Fabien.
--
Sent via pgsql-hackers mailing list (
"git describe" to get something similar:
git describe --long --always --all --dirty
Also there is a need of a fall back if this fails, to get "version>" instead.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Hello,
Fabien COELHO <coe...@cri.ensmp.fr> 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 ...]"
m version 5432.
I would find it useful to have something like that in pg as well, and I
have not found it available.
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.
Thoughts?
--
Fabien.
--
Se
a defect which
triggered the bug. Programming is fun:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that there is another 100% cpu pgbench bug, see
https://commitfest.postgresql.org/15/1292/, which seems more likely to
occur in the wild that this one, but there has been no review of the fix I
sent.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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
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
. Now I understand your purpose.
You may consider something like "BEGIN; UPDATE ...; \sleep 100 ms;
COMMIT;" so that a crash is most likely to occur with plenty transactions
in progress but without much load.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
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 &
not sure the problem was not there
before under one form or another.
I agree that it should error out & stop the client in this case at least.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
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
s is after that...
Maybe you could investigate how it may be implemented on top of that?
Either show times when the phases are performed computed, or maybe use
some auxiliary data structure to keep the information (hmmm...).
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
est could also show a more esoteric sequence (cyclic,
...).
There is no documentation. Maybe none is needed.
I do not understand why some queries have "... \n" "... \n" and others
have "\n ..." "\n ...". I would suggest to homogeneize around the former,
becau
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
e file compressed so that it uses another mime-type and
should not change its contents.
--
Fabien.
psql-server-version-1.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
this is happening.
Yep. I keep the issue of pgbench tap test determinism in my todo list,
among other things.
I think that it should be at least clearer under which condition (load ?
luck ? bug ?) the result may be 1 or 3 when 2 are expected, which needs
some thinking.
--
Fabien.
--
Sent
nions about it. Let's wait and see.
Thanks,
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.post
and maybe you should
consider removing yourself from the "Reviewer" column, otherwise nobody
will provide a review.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
--
Se
s=#
ISTM that this is the expected behavior.
In the first case, "i" is defined, so the test is true and the echo
echoes.
In the second case, "id" is undefined, the test is false and the echo is
skipped.
I do not understand why you conclude that the feature "failed".
--
Fab
data generation message is there.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an option, but that would require more coding and
I'm not sure of the i18n aspect.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ersonnally I'm fine with a pager, so vertical spacing is fine. I just do
not like paging horizontally.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
st for random output.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that a small overhead on a contrived case is worth removing the
feature, as it is really insignificant on any realistic case.
Please read: I do NOT think that...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
is really insignificant on any realistic case.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that it is better this way and there is no strong veto against.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
o that pgbench would work even if
there are no threads, but it also means that under a heavy load some
things may not be done on the target time but a little bit later, if some
thread is stuck somewhere. Although the async protocol try to avoid that.
--
Fabien.
--
Sent via pgsql-hackers mailing list
aggregation. I would rather take a longer test rather than allowing an
empty file: the point is to check that something is generated, but
avoiding a longer test is desirable. So I would suggest to stick to
between 1 and 3, and if it fails then maybe add one second...
--
Fabien.
--
Sent via pgsql-
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
francolin just showed a non-reproducing failure in the new pgbench tests:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin=2017-09-12%2014%3A00%3A02
not ok 211 - transaction count for 001_pgbench_log_1.31583 (3)
# Failed test 'transaction count for
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
feature. However I agree that having libpq always return
some diagnostic, even if it means "something unclear happened, sorry not
to be very precise", would be better.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
but systematic: I use upper-case for all
SQL keywords, and lower-case or capitalized for anything user land. I can
put lower-case if you want.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
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
.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
eue should include tap-tests.
Hopefully one line will be greener on https://coverage.postgresql.org/.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and I
expect there should be half a dozen different opinions on the matter of
formatting.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ms consistent and significant. It suggests a 0.40-0.50 s
difference, that is about 5%, i.e. about (under) 1 µs overhead per
statement in pretty defavorable circumstances.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
, everything is fine from my point of view.
I switched it to "Ready for Committer".
Again, if the pgbench tap test patch get through, it should be tap tested.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
.
Argh, indeed, I totally forgot about translations. Usually there is a _()
hint for gettext.
See
https://www.postgresql.org/docs/devel/static/nls-programmer.html#nls-guidelines
Usually we just use two independent messages, and that's what I did.
Yep, makes sense. Thanks for the fix.
--
Fab
brary functions or client code...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er servers.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
the default, something like:
-i, --ini...
-I, --custom=[...]+ (default "ctgvp")
...
When/if the pgbench tap test patch get through, the feature should be
tested there as well. No action needed now.
--
Fabien.
--
Sent via pgsql-hackers mailing l
where the check is also performed. That
would also simplify a bit the already very large expression evaluation
function.
When/if the pgbench tap test patch get through, coverage tests should
be added.
Maybe the cache overflow could be counted, to allow for a possible warning
message in the final re
rror occured then you had a problem, a
transaction aborted, paying to set a few variables when it occurs does not
look like a big performance issue. Script usually expect to run without
error, errors are rare events.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
SERVER_VERSION_NAME = '7.0.3'
SERVER_VERSION_NUM = '70003'
Looking more closely, I see that when using protocol version 2, libpq
will issue a "select version()" command at connection start to get
this info.
Then it could be used for free to set SERVER_VERSION if it can be
extracted fr
SELECT :SERVER_VERSION_NUM < 11 AS prior_11 \gset
\if :prior_11
-- version 10
\else
-- version 11 or more
\endif
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tty complex, including gotos everywhere.
So I did want to add to these two functions beyond the minimum. Now, I can
also inline everything coldly in ProcessResult, no problem.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
ion available would be
significantly helpful for scripting.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[ 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
my terminal was doing tricks, because I had the impression
that both argument where on the same line with many tabs in between, but
maybe I just misinterpreted the diff file. My apology if it is the case.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
.
I think that the check should silently accept spaces as they are ignored
by init later, i.e.:
sh> ./pgbench -i -I "ctg vpf"
invalid custom initialization script command " "
possible commands are: "c", "t", "g", "v",
be checked.
Anyway, as some tests may have to be skipped on some platforms, it seems
that the done_testing approach is sounder. The v12 patch uses that.
Thanks for your comments.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
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
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
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 extra logged query --- which people are going to
complain about.
Yep.
--
Fabien.
--
Se
testing" may
be a nicer option if some tests need to be skipped on some platform.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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 pgs
unts;"
In passing, I think that the documentation should tell explicitely what
the default value is (aka "ctgvp").
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if the copying data
failed. Maybe we can do TRUNCATE pgbench_accounts, pgbench_history
instead. Thought?
Keep the truncate in the transaction, and truncate both (or all?) tables
together.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
ot;.
HINT: Truncate table "pgbench_history" at the same time, or use TRUNCATE ...
CASCADE.
I think it should work. It probably just mean to TRUNCATE all tables as
one command, or add the suggested CASCADE. I would favor the first option.
I'm wondering whether this truncation should be yet
functions and operators to pgbench
expressions patch is waiting for this to go to ready to committers.
A further caveat to committers: I'm unsure about what happens on Windows.
I've done my best so that it should work.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
ables in reverse foreign key dependencies
order"?
case 'I': ISTM that initialize_cmds is necessarily already allocated, thus
I would not bother to test before pg_free.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 1578 matches
Mail list logo
