Re: pgsql: Refactor script execution state machine in pgbench.
От | Fabien COELHO |
---|---|
Тема | Re: pgsql: Refactor script execution state machine in pgbench. |
Дата | |
Msg-id | alpine.DEB.2.20.1609262212280.28877@lancre обсуждение исходный текст |
Ответ на | Re: pgsql: Refactor script execution state machine in pgbench. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Refactor script execution state machine in pgbench.
Re: pgsql: Refactor script execution state machine in pgbench. |
Список | pgsql-committers |
Hello Tom, > There's at least one bug in this patch. Indeed. > It's caused pgbench to go into an infinite loop during the TAP tests on > my buildfarm machine longfin. > > buildfarm 719:14.18 /Users/buildfarm/bf-data/HEAD/inst/bin/pgbench --no-vacuum --client=5 --protocol=prepared --transactions=25--file /Users/buildfarm/bf-data/HEAD/pgsql.build/src/bin/pgbench/tmp_check/data_main_JNh2/pgbench_script > > Some other buildfarm critters seem to have got through that successfully, > so it's probably a portability issue not a hard failure. Hmmm, not easy to identify, especially as I do not have a clang on MacOS... Could you catch the process to identify the infinite loop? What are the states of the five clients? I think that it may be stuck in doCustom or on threadRun. I'm not sure how it could be stuck in doCustom. Re-reading the code, I think that the "end_tx_processed" stuff could be removed in favor of a systematic return at the end of the transaction, but that does not explain anything wrt to an infinite loop: after 25 transactions it should have got to FINISHED and have exited. Maybe it can be stuck in threadRun in the "while (remains>0)" loop, which suggests that a remains-- has been forgotten... but I do not see how this is possible to forget a client by reading the code. So although I hastily declared that bugs would be easier to detect, without any additional clue it is hard to help. -- Fabien.
В списке pgsql-committers по дате отправления: