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?