>
>
>
> I see this in pgbench.c:
>
> /* return false iff client should be disconnected */
> static bool
> doCustom(CState *st, instr_time *conn_time)
>
> I think you need to increase the verbosity of the error messages when
> you're working on this code, because when I compile I get a slew of th
On Tue, 22 Sep 2009, Michael Paquier wrote:
The function doCustom is defined with a void.
I see this in pgbench.c:
/* return false iff client should be disconnected */
static bool
doCustom(CState *st, instr_time *conn_time)
I think you need to increase the verbosity of the error messag
See attached a patch of this setshell feature.
If you use in a script file something like:
/setshell param_set setshellparam.sh
pgbench reads from the shell script setshellparam.sh the first output value,
verifies if it is an integer, then manages it as a pgbench parameter.
I did not take into acc
On Tue, 22 Sep 2009, Michael Paquier wrote:
Besides, you can also make tests without 2pc transactions, such as:
\shell ls -ll /home/ioltas/usr/pgsql/data
END;
I think that demonstrating the pgbench shell feature with this 2PC example
is working against your patch being even considered, much l
Hi,
Sorry for my late reply again :o)
You will find my answers on-the-line.
> > You really should be returning a value at the point since the function
> > signature defines a return type. If not the function should be void,
> > which it cannot be in this context since it is used for boolean tests
On Fri, Sep 18, 2009 at 03:10:14PM +0900, Michael Paquier wrote:
> >
> > You really should be returning a value at the point since the function
> > signature defines a return type. If not the function should be void,
> > which it cannot be in this context since it is used for boolean tests
> > else
>
> You really should be returning a value at the point since the function
> signature defines a return type. If not the function should be void,
> which it cannot be in this context since it is used for boolean tests
> elsewhere. The returns in question are all part of error blocks and
> should re
On Thu, Sep 17, 2009 at 09:56:44AM +0900, Michael Paquier wrote:
> Hi all,
>
> Sorry for my late reply.
> There is no other update for this patch since the 13th of August, at least
> until today. The new patch is attached
> By the way I worked on the comments that Dan and Gabriel pointed out.
> I
Hi all,
Sorry for my late reply.
There is no other update for this patch since the 13th of August, at least
until today. The new patch is attached
By the way I worked on the comments that Dan and Gabriel pointed out.
I added a check on system such as to prevent an error from this side.
By the way,
On Tue, Sep 15, 2009 at 09:53:11PM -0400, Stephen Frost wrote:
> Michael,
>
> I just wanted to follow-up on your pgbench patch. The latest version
> that I see is from August 13th. Is that the correct patch to be
> reviewing? Do you have any other updates on it?
>
> Thanks!
>
>
Michael,
I just wanted to follow-up on your pgbench patch. The latest version
that I see is from August 13th. Is that the correct patch to be
reviewing? Do you have any other updates on it?
Thanks!
Stephen
signature.asc
Description: Digital signature
Thanks a lot for all of your pieces of advice.
I modified the name of the page as well as I deleted the parts linked to the
-P option.
It just consisted in deleting the right parts.
Here is the lighted version.
--
Michael Paquier
NTT OSSC
postgresql-8.4.0-pgbenchshell2.0.patch
Description: Bi
Yes it dramatically decreases the transaction flow.
This function has not been implemented at all for performance but for
analysis purposes.
I used it mainly to have a look at state files size in pg_twophase for
transactions that are prepared but not committed.
Regards
On Fri, Aug 7, 2009 at 12:5
Michael Paquier escribió:
> I also created a page in postgresql's wiki about this feature.
> Please refer to this link:
> http://wiki.postgresql.org/wiki/Pgbench:_shell_command
Please don't use colons in wiki page names. Pgbench_shell_command
should be fine.
--
Alvaro Herrera
Michael Paquier wrote:
> > Here is a short patch implementing a new feature in pgbench so as to allow
> > shell commands to be launched in a transaction file of pgbench.
> > \shell ls ~/pg_twophase;
+1 for \shell command itself, but does the performance fit for your purpose?
Spawning a new proc
On Thu, Aug 6, 2009 at 11:26 PM, Michael
Paquier wrote:
> Sorry I forgot to attach the the patch.
Please add your patches at
https://commitfest.postgresql.org/action/commitfest_view/open
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Sorry I forgot to attach the the patch.
Regards,
Michael
On Fri, Aug 7, 2009 at 12:23 PM, Michael Paquier
wrote:
> Hi all,
>
> Here is a short patch implementing a new feature in pgbench so as to allow
> shell commands to be launched in a transaction file of pgbench.
> the user has just to add
Hi all,
Here is a short patch implementing a new feature in pgbench so as to allow
shell commands to be launched in a transaction file of pgbench.
the user has just to add at the beginning of the command line in his
transaction file \shell + the command wanted.
As an example of transaction:
Begin
18 matches
Mail list logo
