Re: [HACKERS] Variable substitution in psql backtick expansion

2017-11-12 Thread Fabien COELHO
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

Re: [HACKERS] Add some const decorations to prototypes

2017-11-10 Thread Fabien COELHO
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

Re: [HACKERS] proposal: psql command \graw

2017-11-10 Thread Fabien COELHO
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;

Re: [HACKERS] Add some const decorations to prototypes

2017-11-10 Thread Fabien COELHO
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

Re: [HACKERS] Add some const decorations to prototypes

2017-11-10 Thread Fabien COELHO
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

Re: [HACKERS] proposal: psql command \graw

2017-11-09 Thread Fabien COELHO
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

Re: [HACKERS] proposal: psql command \graw

2017-11-09 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] Add some const decorations to prototypes

2017-11-04 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - allow to store select results into variables

2017-11-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - use enum for meta commands

2017-11-02 Thread Fabien COELHO
[ 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:

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

2017-11-02 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - use enum for meta commands

2017-11-02 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - use enum for meta commands

2017-11-02 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - allow to store select results into variables

2017-10-20 Thread Fabien COELHO
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

Re: [HACKERS] pgbench more operators & functions

2017-10-20 Thread Fabien COELHO
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 ---

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-10-20 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-10-17 Thread Fabien COELHO
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

Re: [HACKERS] show precise repos version for dev builds?

2017-10-14 Thread Fabien COELHO
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

Re: [HACKERS] show precise repos version for dev builds?

2017-10-13 Thread Fabien COELHO
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

Re: [HACKERS] show precise repos version for dev builds?

2017-10-12 Thread Fabien COELHO
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

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

2017-10-04 Thread Fabien COELHO
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.

Re: [HACKERS] show precise repos version for dev builds?

2017-10-01 Thread Fabien COELHO
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 ...]"

[HACKERS] show precise repos version for dev builds?

2017-10-01 Thread Fabien COELHO
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:

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2017-09-29 Thread Fabien COELHO
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

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-29 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2017-09-29 Thread Fabien COELHO
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:

Re: [HACKERS] plpgsql_check future

2017-09-29 Thread Fabien COELHO
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

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-29 Thread Fabien COELHO
- 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,

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Fabien COELHO
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 &

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Fabien COELHO
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,

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

2017-09-25 Thread Fabien COELHO
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. --

Re: [HACKERS] PATCH: pgbench - break out timing data for initialization phases

2017-09-25 Thread Fabien COELHO
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

Re: [HACKERS] psql \d sequence display

2017-09-25 Thread Fabien COELHO
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

[HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

2017-09-24 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-24 Thread Fabien COELHO
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-23 Thread Fabien COELHO
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

[HACKERS] pgbench - use enum for meta commands

2017-09-22 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-22 Thread Fabien COELHO
[...] 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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-21 Thread Fabien COELHO
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,

Re: [HACKERS] psql - add ability to test whether a variable exists

2017-09-20 Thread Fabien COELHO
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:

Re: [HACKERS] psql - add ability to test whether a variable exists

2017-09-20 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-20 Thread Fabien COELHO
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

Re: [HACKERS] psql - add ability to test whether a variable exists

2017-09-20 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-18 Thread Fabien COELHO
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.

Re: [HACKERS] psql: new help related to variables are not too readable

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] psql: new help related to variables are not too readable

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] psql: new help related to variables are not too readable

2017-09-13 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-12 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-12 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-12 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-12 Thread Fabien COELHO
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

Re: [HACKERS] pgbench regression test failure

2017-09-12 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2017-09-11 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-11 Thread Fabien COELHO
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.

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-11 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2017-09-11 Thread Fabien COELHO
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

Re: [HACKERS] pgbench more operators & functions

2017-09-10 Thread Fabien COELHO
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. --

Re: [HACKERS] pgbench more operators & functions

2017-09-09 Thread Fabien COELHO
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

[HACKERS] Re: [COMMITTERS] pgsql: Fix assorted portability issues in new pgbench TAP tests.

2017-09-08 Thread Fabien COELHO
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...

Re: [HACKERS] pgbench - allow to store select results into variables

2017-09-08 Thread Fabien COELHO
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

Re: [HACKERS] pgbench tap tests & minor fixes.

2017-09-08 Thread Fabien COELHO
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

Re: [HACKERS] psql: new help related to variables are not too readable

2017-09-07 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-07 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-07 Thread Fabien COELHO
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,

Re: [HACKERS] merge psql ef/ev sf/sv handling functions

2017-09-06 Thread Fabien COELHO
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, -

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Fabien COELHO
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...).

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

2017-09-06 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-05 Thread Fabien COELHO
* 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

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-05 Thread Fabien COELHO
[ 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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] pgbench tap tests & minor fixes.

2017-09-05 Thread Fabien COELHO
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

Re: [HACKERS] pgbench tap tests & minor fixes.

2017-09-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2017-09-04 Thread Fabien COELHO
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-04 Thread Fabien COELHO
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: [HACKERS] pgbench tap tests & minor fixes.

2017-09-04 Thread Fabien COELHO
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,

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench - allow to store select results into variables

2017-09-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-04 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-01 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-09-01 Thread Fabien COELHO
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".

Re: [HACKERS] pgbench tap tests & minor fixes.

2017-08-31 Thread Fabien COELHO
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

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

2017-08-31 Thread Fabien COELHO
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

  1   2   3   4   5   6   7   8   9   10   >