RE: [HACKERS] Anyone object to simplifying INSTALL instructions?
От | Jackson, DeJuan |
---|---|
Тема | RE: [HACKERS] Anyone object to simplifying INSTALL instructions? |
Дата | |
Msg-id | F10BB1FAF801D111829B0060971D839F490CF3@cpsmail обсуждение исходный текст |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: