> It's been quite some time since it was necessary to run the postmaster
> with a specific TZ setting in order to do the regression tests.  I see
> that the instructions to change TZ have been removed from install.sgml
> (though not yet from the text INSTALL file).  But the instructions
> still
> tell you to start a postmaster for the regression test, then kill it
> and
> start another one for production use.  Seems to me we could just
> rearrange the order of the steps: start the postmaster normally,
> *then*
> run the regression tests if you feel like it.  Is there a reason not
> to
> simplify the instructions that way?
> 
> 			regards, tom lane
> 
> PS: Actually, what we really need is an easy way to run the regression
> tests on a new build without having to disturb the production
> installation until you know the new build works.  (Everyone else does
> "make test" *before* "make install" ... with pgsql you have to do it
> the
> other way around.  Not good for mission-critical software.)
> 
> Right now I think this requires configuring, building, installing with
> nonstandard values of POSTGRESDIR and PGPORT, then running the
> regression test in that environment, then (if successful) throwing
> away
> all that work and repeating the build with standard configuration so
> you
> can install it live.  Bleah.  And you still run the risk of blowing it
> by misconfiguring the second time around.
> 
> What I really want to be able to run the regression test on the
> software
> sitting in the build tree, without doing an install at all.  Any
> thoughts on what it would take to do that?
Why not just use the -D and -p postmaster options to the current
configuration to supply a test port and a DataDir in the src tree. The
Datadir would have to already be initdb'd (I'm not sure how this would
work).
	-DEJ

Wed, 21 Oct 1998 11:32:42 -0500
"Jackson, DeJuan" <djackson@cpsgroup.com>
RE: [HACKERS] Anyone object to simplifying INSTALL instructions?