[HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
В списке pgsql-hackers по дате отправления:
| От | Marina Polyakova |
|---|---|
| Тема | [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors |
| Дата | |
| Msg-id | 72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru обсуждение исходный текст |
| Ответы |
Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors |
| Список | pgsql-hackers |
Hello, hackers! Now in pgbench we can test only transactions with Read Committed isolation level because client sessions are disconnected forever on serialization failures. There were some proposals and discussions about it (see message here [1] and thread here [2]). I suggest a patch where pgbench client sessions are not disconnected because of serialization or deadlock failures and these failures are mentioned in reports. In details: - transaction with one of these failures continue run normally, but its result is rolled back; - if there were these failures during script execution this "transaction" is marked appropriately in logs; - numbers of "transactions" with these failures are printed in progress, in aggregation logs and in the end with other results (all and for each script); Advanced options: - mostly for testing built-in scripts: you can set the default transaction isolation level by the appropriate benchmarking option (-I); - for more detailed reports: to know per-statement serialization and deadlock failures you can use the appropriate benchmarking option (--report-failures). Also: TAP tests for new functionality and changed documentation with new examples. Patches are attached. Any suggestions are welcome! P.S. Does this use case (do not retry transaction with serialization or deadlock failure) is most interesting or failed transactions should be retried (and how much times if there seems to be no hope of success...)? [1] https://www.postgresql.org/message-id/4EC65830020000250004323F%40gw.wicourts.gov [2] https://www.postgresql.org/message-id/flat/alpine.DEB.2.02.1305182259550.1473%40localhost6.localdomain6#alpine.DEB.2.02.1305182259550.1473@localhost6.localdomain6 -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера