Re: [PATCH] pgbench: new feature allowing to launch shell commands - Mailing list pgsql-hackers

Hi,<br /><br />Sorry for my late reply again :o)<br />You will find my answers on-the-line.<br /><br />> > You
reallyshould be returning a value at the point since the function<br /> > > signature defines a return type. If
notthe function should be void,<br /> > > which it cannot be in this context since it is used for boolean
tests<br/> > > elsewhere. The returns in question are all part of error blocks and<br /> > > should return
false.<br/><br />The function doCustom is defined with a void.<br />I agree that it is far cleaner to return a value
butby returning in my own code part a boolean or an integer, it will have a large impact on other parts of the code
thatare dealing with the original command types of pgbench.<br /> By the way, the errors created by doCustom are
managedthrough CState for each customer, so letting it like it is is far sufficient and has no impact on other parts of
thecode.<br /><br />> So I get this output with and with out the shell command in there,<br /> > against the
unpatchedand patched version on pgbench. The commands you<br /> > sent will not work with this script since it is
usingprepared<br /> > statements. I am using this command to run the script.<br /><br />I made on my side a couple
oftests to see what is happening in the code.<br />The problem you saw is not linked to the patch I wrote.<br />In fact
whenyou are using the prepared statement mode, PQprepare seems not to be able to manage with the parameter I put in my
transactionscript at "prepare transaction" and "commit prepared" stages. This parameter is the random ID used for
preparedtransaction.<br /> If you try an end script such as:<br />PREPARE TRANSACTION 'T';<br />\shell ls -ll
~/pgsql/data<br/>COMMIT PREPARED 'T';<br />It will work without any problem in both prepared and single query mode.<br
/><br/>For 1 customer, there is no issue. However, by increasing the number of customers, it will increase the risk for
acustomer to prepare a transaction who is using a same 2pc ID, resulting in a couple of output errors.<br /> Using the
originalscript I wrote is OK in single query mode, as 2pc ID is not managed by PQprepare but at pgbench level. This way
pgbenchwill not create errors, as it builds an individual query with a random ID one by one. The prepared query mode
preparesthe same transaction for all the customers of pgbench, and I think that PQprepare cannot manage 2pc IDs while
preparinga transaction. Parameters in SQL queries is OK, but not at prepare states.<br /> That would explain why in
thiscase, the system was looking for a parameter that is not delivered initially.<br /><br />Besides, you can also make
testswithout 2pc transactions, such as:<br />\shell ls -ll /home/ioltas/usr/pgsql/data<br /> END;<br />In this case
alsoit works finely in both prepared and single query mode (at least on my side :)).<br /><br />By looking at the
documentationof pgbench, prepared query mode is used for performance purposes only. The pgbench shell feature tends to
slowdown all the process as it has been created for analysis purposes only, so the single query mode is enough to my
mindif you want to study the interactions of your system and postgres.<br /><br />Regards,<br /><br />Michael<br />