Re: Regression tests versus the buildfarm environment - Mailing list pgsql-hackers

From Vik Reykja
Subject Re: Regression tests versus the buildfarm environment
Date
Msg-id AANLkTi=aDvU3yrmSpzAD7VV+fzZk-5pnF2d30Ci5Vtbi@mail.gmail.com
Whole thread Raw
In response to Regression tests versus the buildfarm environment  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Regression tests versus the buildfarm environment
List pgsql-hackers
<div class="gmail_quote">On Wed, Aug 11, 2010 at 06:42, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div id=":1h2">I am not
sureif there's anything very good we can do about the<br /> problem of pg_regress misidentifying the postmaster it's
managedto<br /> connect to.  A real solution would probably be much more trouble than<br /> it's worth, anyway.
 However,it does seem like we ought to be able to<br /> do something about two buildfarm critters defaulting to the
samechoice<br /> of port number.  The buildfarm infrastructure goes to great lengths to<br /> pick nonconflicting port
numbersfor the "installed" postmasters it<br /> runs; but we're ignoring all that effort and just using a hardwired<br
/>port number for "make check".  This is dumb.<br /><br /> pg_regress does have a --port argument that can be used to
override<br/> that default.  I don't know whether the buildfarm script calls<br /> pg_regress directly or does "make
check". If the latter, we'd need to<br /> twiddle the Makefiles to allow a port number to get passed in.  But<br />
thisseems well worthwhile to me.<br /><br /> Comments?</div></blockquote></div><br />We just put in the possibility to
namethe client connections.  Would it be interesting to be able to name the server installation itself?<br /> 

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Bug / shortcoming in has_*_privilege
Next
From: Simon Riggs
Date:
Subject: Re: assertions and constraint triggers