> 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