* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, May 12, 2015 at 12:08 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It's says:
starting vacuum ERROR: blah
ERROR: blah
ERROR: blah
done
And then continues on. Sure, that's not
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, May 12, 2015 at 12:08 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It's says:
starting vacuum ERROR: blah
ERROR: blah
ERROR: blah
done
And then continues on. Sure, that's not
* Robert Haas (robertmh...@gmail.com) wrote:
It's says:
starting vacuum ERROR: blah
ERROR: blah
ERROR: blah
done
And then continues on. Sure, that's not the greatest error reporting
output ever, but what do you expect from pgbench? I think it's clear
enough what's going on there.
On Tue, May 12, 2015 at 12:08 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It's says:
starting vacuum ERROR: blah
ERROR: blah
ERROR: blah
done
And then continues on. Sure, that's not the greatest error reporting
output ever, but what do
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But as far as what has been discussed on the central topic of this thread, I
think that doing the vacuum and making the failure for non-existent tables
be non-fatal when -f is
On Thu, Apr 30, 2015 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But as far as what has been discussed on the central topic of this thread, I
think that doing the vacuum and
On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But as far as what has been discussed on the central topic of this thread, I
think that doing the vacuum and making the failure for non-existent tables
be non-fatal when -f is provided would be an improvement. Or maybe
On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I would rather just learn to add the -n when I use -f
and don't have the default tables in place, than have to learn new methods
for saying no really, I left -n off on purpose when I have a custom file
which does use the
On Tue, Dec 23, 2014 at 7:42 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a completely different idea. How about we add an option that
means vacuum this table before running
On 2/10/15 3:12 AM, Michael Paquier wrote:
On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
- The documentation misses some markups for pgbench and VACUUM and did
not respect the 80-character limit.
I didn't realize that there's such a style guide. Although I think
it's a good thing, I
On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote:
Agreed. Here is the patch to implement the idea: -f just implies -n.
Some small comments:
- is_no_vacuum, as well as is_init_mode, are defined as an integers
but their use imply that they are boolean switches. This patch sets
is_no_vacuum
On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
- The documentation misses some markups for pgbench and VACUUM and did
not respect the 80-character limit.
I didn't realize that there's such a style guide. Although I think
it's a good thing, I just want to know where such a guide is
On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
- The documentation misses some markups for pgbench and VACUUM and did
not respect the 80-character limit.
I didn't realize that there's such a style guide. Although I think
it's a good thing, I just want to know where such a guide is
On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote:
Agreed. Here is the patch to implement the idea: -f just implies -n.
Some small comments:
- is_no_vacuum, as well as is_init_mode, are defined as an integers
but their use imply that they are boolean switches. This patch sets
is_no_vacuum to
Although that might be taking this thread rather far off-topic.
Not really sure about that, because the only outstanding objection to
this discussion is what happens in the startup stage if you specify -f.
Right now vacuum is attempted on the standard tables, which is probably
not the right
On Wed, Dec 24, 2014 at 12:42 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Although that might be taking this thread rather far off-topic.
Not really sure about that, because the only outstanding objection to
this discussion is what happens in the startup stage if you specify -f.
Right
On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a completely different idea. How about we add an option that
means vacuum this table before running the test (can be given several
times); by default the set of vacuumed tables is the current pgbench_*
Robert Haas wrote:
On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a completely different idea. How about we add an option that
means vacuum this table before running the test (can be given several
times); by default the set of vacuumed tables is the
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(2) The 'executeStatement2' API is a bit awkward as the signarure
executeStatement2(PGconn *con, const char *sql, const char *table);
suggests that the 'sql' command is executed when 'table' exists.
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define function prototypes for
executeStatement2 and is_table_exists. It certainly is not
consistent with the other functions defined in
On 22.12.2014 17:47, Alvaro Herrera wrote:
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define function prototypes for
executeStatement2 and is_table_exists. It certainly is not
Tomas Vondra wrote:
I'm not objecting to prototypes in general, but I believe the principle
is to respect how the existing code is written. There are almost no
other prototypes in pgbench.c - e.g. there are no prototypes for
executeStatement(), init() etc. so adding the prototypes in this
On 2014-12-22 18:17:56 +0100, Tomas Vondra wrote:
On 22.12.2014 17:47, Alvaro Herrera wrote:
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define function prototypes for
On 22.12.2014 18:41, Andres Freund wrote:
On 2014-12-22 18:17:56 +0100, Tomas Vondra wrote:
On 22.12.2014 17:47, Alvaro Herrera wrote:
Tomas Vondra wrote:
On 22.12.2014 07:36, Tatsuo Ishii wrote:
On 22.12.2014 00:28, Tomas Vondra wrote:
(8) Also, I think it's not necessary to define
First of all - I'm not entirely convinced the IF EXISTS approach is
somehow better than -f implies -n suggested before, but I don't have a
strong preference either.
I revisited the -f implies -n approach again. The main reason why I
wanted to avoid the approach was, it breaks the backward
Here's a completely different idea. How about we add an option that
means vacuum this table before running the test (can be given several
times); by default the set of vacuumed tables is the current pgbench_*
list, but if -f is specified then the default set is cleared. So if you
have a -f
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org wrote:
If we care enough about that case to attempt the vacuum anyway then we
need to do something about the error message; either squelch it or
check for the existence of the tables before attempting to
vacuum. Since there's
On Sun, Dec 21, 2014 at 12:58 PM, Tatsuo Ishii is...@postgresql.org wrote:
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org
wrote:
If we care enough about that case to attempt the vacuum anyway then we
need to do something about the error message; either squelch it or
- Error to apply to the current master:
Works for me.
$ git apply ~/pgbench-f-noexit-v2.patch
$
Maybe git version difference or the patch file was malformed by mail
client?
+static void executeStatement2(PGconn *con, const char *sql, const char
*table);
I think we can use a better name
Hi,
On 21.12.2014 15:58, Tatsuo Ishii wrote:
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org wrote:
If we care enough about that case to attempt the vacuum anyway
then we need to do something about the error message; either
squelch it or check for the existence of the
Hi,
On 21.12.2014 15:58, Tatsuo Ishii wrote:
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org wrote:
If we care enough about that case to attempt the vacuum anyway
then we need to do something about the error message; either
squelch it or check for the existence of the
On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii is...@postgresql.org wrote:
If we care enough about that case to attempt the vacuum anyway then we
need to do something about the error message; either squelch it or
check for the existence of the tables before attempting to
vacuum. Since there's
On Sat, Dec 13, 2014 at 10:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or --no-vacuum)
is not specified. If those tables do not exist,
On 2014-12-15 10:55:30 -0800, Jeff Janes wrote:
On Sat, Dec 13, 2014 at 7:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or --no-vacuum)
is not specified. If those tables do not exist, pgbench fails. To
prevent this, -n must be specified. For me this behavior seems insane
because -f does not
Tatsuo Ishii is...@postgresql.org writes:
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or --no-vacuum)
is not specified. If those tables do not exist, pgbench fails. To
prevent this, -n must be specified. For me this
On 14 December 2014 at 04:39, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or --no-vacuum)
is not specified. If those tables do not exist,
On 14 December 2014 at 04:39, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
Currently pgbench -f (run custom script) executes vacuum against
pgbench_* tables before stating bench marking if -n (or --no-vacuum)
is not specified. If those tables do not exist,
On 12/13/14, 6:17 PM, Tatsuo Ishii wrote:
Problem with -f implies -n approach is, it breaks backward
compatibility. There are use cases using custom script*and* pgbench_*
tables. For example the particular user wants to use the standard
pgbench tables and is not satisfied with the built in
39 matches
Mail list logo
