Fabien COELHO , Kevin Grittner, Andres Freund , Alvaro Herrera, Thomas Munro ,Robert Haas

Поиск
Список
Период
Сортировка
От Marina Polyakova
Тема Fabien COELHO , Kevin Grittner, Andres Freund , Alvaro Herrera, Thomas Munro ,Robert Haas
Дата
Msg-id eca14b85c686f1049091f8c1f631854b@postgrespro.ru
обсуждение исходный текст
Список pgsql-hackers
Hello, hackers!

This is the fourth version of the patch for pgbench. As in the previous 
one, most of the changes were made thanks to the comments of Fabien 
Coelho. Here I propose not to abort the client in pgbench in case of 
various errors including unsuccessful meta commands. As in the previous 
version, transactions with serialization and deadlock failures are 
rolled back and retried until they end successfully or their number of 
tries reaches maximum.

In details:
* Client's run is aborted only in case of a serious error, for example, 
the connection with the backend was lost. Otherwise if the execution of 
SQL or meta command fails, the client's run continues normally, except 
that the current transaction block terminates if possible.
* If a failed transaction block cannot terminate in the current script, 
its commands after the error as well as the commands of the following 
scripts are processed as usual so you can get a lot of errors of type 
"in failed SQL transaction" (when the current SQL transaction is aborted 
and commands ignored until end of transaction block). In such cases you 
can use separate statistics of these errors in all reports.

The main differences from the previous version:
* support for compound commands (as I understand, they are not properly 
supported in the original version, since the execution status is 
processed only for the first subcommand). Note that:
** not all compound commands that contain subcommands to start or end an 
explicit transaction block can be retried. For example, you cannot use a 
compound command to complete a failed transaction block before retrying. 
Also if there're any subcommands before the explicit transaction block, 
the latter cannot be retried from the very beginning.
** if you want to know which subcommands of compound SQL commands 
failed, use the debug output.
* do not divide retries by type in all reports (you can get this 
information from the debug output).
* (because of all of the above) option --debug-fails. If you want to 
distinguish between failures or errors by type, or you want to know 
which subcommands of compound SQL commands failed, use the the pgbench 
debugging output created with the option --debug-fails or --debug. The 
first option is recommended for this purpose because with the second 
option the debugging output can be very large.
* tests for serialization/deadlock errors and retries use advisory locks 
(as I wrote here [1] other more simple methods can sometimes fail); and 
they became lighter (28 simple tests instead of 57, 8 runs of pgbench 
instead of 17).

Other smaller differences from the previous version:
* receive information from the server whether we are in the transaction 
block or not;
* naming fix (I will be very grateful if a native English speaker 
comments on this): failures are errors if they cannot be retried;
* as usual, code cleanup; in particular, use states instead of the bool 
variables to complete a failed transaction block.

Patch is attached. Any suggestions are welcome!

[1] 
https://www.postgresql.org/message-id/e4c5e8cefa4a8e88f1273b0f1ee29e56%40postgrespro.ru

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Tracking of page changes for backup purposes. PTRACK [POC]
Следующее
От: Marina Polyakova
Дата:
Сообщение: WIP Patch: Pgbench Serialization and deadlock errors