Re: [HACKERS] pgbench randomness initialization - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] pgbench randomness initialization
Date
Msg-id alpine.DEB.2.20.1803010750440.7903@lancre
Whole thread Raw
In response to Re: [HACKERS] pgbench randomness initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgbench randomness initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Rajkumar Raghuwanshi
Date:
Subject: Re: server crash in nodeAppend.c
Next
From: Craig Ringer
Date:
Subject: Re: Two-phase update of restart_lsn in LogicalConfirmReceivedLocation