Re: [HACKERS] pgbench randomness initialization
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench randomness initialization |
Дата | |
Msg-id | alpine.DEB.2.20.1803010750440.7903@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench randomness initialization (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pgbench randomness initialization
|
Список | pgsql-hackers |
Hello Tom, > Fabien COELHO <coelho@cri.ensmp.fr> writes: >>> This is a simple patch that does what it says on the tin. I ran into >>> trouble with the pgbench TAP test *even before applying the patch*, but >>> only because I was doing a VPATH build as a user without 'write' >>> on the source tree (001_pgbench_with_server.pl tried to make pgbench >>> create log files there). Bad me. Oddly, that was the only test in the >>> whole tree to have such an issue, so here I add a pre-patch to fix that. >>> Now my review needs a review. :) > >> Yep. I find the multiple chdir solution a little bit too extreme. > >> ISTM that it should rather add the correct path to --log-prefix by >> prepending $node->basedir, like the pgbench function does for -f scripts. >> See attached. > > Hm ... so I tried to replicate this problem, and failed to: the log files > get made under the VPATH build directory, as desired, even without this > patch. Am I doing something wrong, or is this platform-dependent somehow? As I recall, it indeed works if the source directories are rw, but fails if they are ro because then the local mkdir fails. So you would have to do a vpath build with sources that are ro to get the issue the patch is fixing. Otherwise, the issue would have been cought earlier by the buildfarm, which I guess is doing vpath compilation and full validation. -- Fabien.
В списке pgsql-hackers по дате отправления: