Обсуждение: pg_regress --temp-keep
add boolean option --temp-keep to pg_regress to keep the existing tmp_check installation, instead of overwriting it with a fresh make install. Useful to test minor modifications in the current tmp_check installation. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ *** src/test/regress/pg_regress.sh.orig Wed Sep 22 21:11:19 2004 --- src/test/regress/pg_regress.sh Fri Oct 15 12:38:00 2004 *************** *** 21,26 **** --- 21,27 ---- --schedule=FILE use test ordering schedule from FILE (may be used multiple times to concatenate) --temp-install[=DIR] create a temporary installation (in DIR) + --temp-keep keep existing temporary installation Options for \`temp-install' mode: --top-builddir=DIR (relative) path to top level build directory *************** *** 90,95 **** --- 91,97 ---- unset debug unset top_builddir unset temp_install + unset temp_keep unset multibyte dbname=regression *************** *** 127,132 **** --- 129,137 ---- --temp-install=*) temp_install=`expr "x$1" : "x--temp-install=\(.*\)"` shift;; + --temp-keep) + temp_keep=yes + shift;; --max-connections=*) maxconnections=`expr "x$1" : "x--max-connections=\(.*\)"` shift;; *************** *** 358,389 **** ;; esac ! if [ -d "$temp_install" ]; then message "removing existing temp installation" rm -rf "$temp_install" ! fi ! message "creating temporary installation" ! if [ ! -d "$LOGDIR" ]; then mkdir -p "$LOGDIR" || { (exit 2); exit; } ! fi ! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 ! if [ $? -ne 0 ] ! then echo echo "$me: installation failed" echo "Examine $LOGDIR/install.log for the reason." echo (exit 2); exit ! fi ! # fix conversion shared objs path ! conv=$datadir/conversion_create.sql ! backup=$conv.bak ! mv $conv $backup ! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv ! rm $backup message "initializing database system" [ "$debug" = yes ] && initdb_options='--debug' --- 363,398 ---- ;; esac ! if [ "$temp_keep" = "yes" ]; then ! message "keeping existing temp installation" ! else ! if [ -d "$temp_install" ]; then message "removing existing temp installation" rm -rf "$temp_install" ! fi ! message "creating temporary installation" ! if [ ! -d "$LOGDIR" ]; then mkdir -p "$LOGDIR" || { (exit 2); exit; } ! fi ! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 ! if [ $? -ne 0 ] ! then echo echo "$me: installation failed" echo "Examine $LOGDIR/install.log for the reason." echo (exit 2); exit ! fi ! # fix conversion shared objs path ! conv=$datadir/conversion_create.sql ! backup=$conv.bak ! mv $conv $backup ! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv ! rm $backup ! fi # eof temp_keep message "initializing database system" [ "$debug" = yes ] && initdb_options='--debug'
Uh, why would someone use this option? --------------------------------------------------------------------------- Reini Urban wrote: > add boolean option --temp-keep to pg_regress to keep the existing > tmp_check installation, instead of overwriting it with a fresh make > install. Useful to test minor modifications in the current tmp_check > installation. > -- > Reini Urban > http://xarch.tu-graz.ac.at/home/rurban/ > *** src/test/regress/pg_regress.sh.orig Wed Sep 22 21:11:19 2004 > --- src/test/regress/pg_regress.sh Fri Oct 15 12:38:00 2004 > *************** > *** 21,26 **** > --- 21,27 ---- > --schedule=FILE use test ordering schedule from FILE > (may be used multiple times to concatenate) > --temp-install[=DIR] create a temporary installation (in DIR) > + --temp-keep keep existing temporary installation > > Options for \`temp-install' mode: > --top-builddir=DIR (relative) path to top level build directory > *************** > *** 90,95 **** > --- 91,97 ---- > unset debug > unset top_builddir > unset temp_install > + unset temp_keep > unset multibyte > > dbname=regression > *************** > *** 127,132 **** > --- 129,137 ---- > --temp-install=*) > temp_install=`expr "x$1" : "x--temp-install=\(.*\)"` > shift;; > + --temp-keep) > + temp_keep=yes > + shift;; > --max-connections=*) > maxconnections=`expr "x$1" : "x--max-connections=\(.*\)"` > shift;; > *************** > *** 358,389 **** > ;; > esac > > ! if [ -d "$temp_install" ]; then > message "removing existing temp installation" > rm -rf "$temp_install" > ! fi > > ! message "creating temporary installation" > ! if [ ! -d "$LOGDIR" ]; then > mkdir -p "$LOGDIR" || { (exit 2); exit; } > ! fi > ! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 > > ! if [ $? -ne 0 ] > ! then > echo > echo "$me: installation failed" > echo "Examine $LOGDIR/install.log for the reason." > echo > (exit 2); exit > ! fi > > ! # fix conversion shared objs path > ! conv=$datadir/conversion_create.sql > ! backup=$conv.bak > ! mv $conv $backup > ! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv > ! rm $backup > > message "initializing database system" > [ "$debug" = yes ] && initdb_options='--debug' > --- 363,398 ---- > ;; > esac > > ! if [ "$temp_keep" = "yes" ]; then > ! message "keeping existing temp installation" > ! else > ! if [ -d "$temp_install" ]; then > message "removing existing temp installation" > rm -rf "$temp_install" > ! fi > > ! message "creating temporary installation" > ! if [ ! -d "$LOGDIR" ]; then > mkdir -p "$LOGDIR" || { (exit 2); exit; } > ! fi > ! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 > > ! if [ $? -ne 0 ] > ! then > echo > echo "$me: installation failed" > echo "Examine $LOGDIR/install.log for the reason." > echo > (exit 2); exit > ! fi > > ! # fix conversion shared objs path > ! conv=$datadir/conversion_create.sql > ! backup=$conv.bak > ! mv $conv $backup > ! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv > ! rm $backup > ! fi # eof temp_keep > > message "initializing database system" > [ "$debug" = yes ] && initdb_options='--debug' > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reini Urban <rurban@x-ray.at> writes:
> add boolean option --temp-keep to pg_regress to keep the existing
> tmp_check installation, instead of overwriting it with a fresh make
> install. Useful to test minor modifications in the current tmp_check
> installation.
This doesn't seem like a particularly good idea ... what's it going to
buy you except another way to shoot yourself in the foot?
What I'd rather see is some effort spent on speeding up our "install"
script, maybe by allowing it to install multiple files per invocation.
The recent changes to force install-all-headers have caused a
serious degradation of "make install" performance, and I think that's
where the issue really needs to be solved.
regards, tom lane
Bruce Momjian schrieb: > Uh, why would someone use this option? after fixing a minor issue, not to wait for a full de-install / install and test database loss. minor issues can be regression tests updates, or updated single binaries. > --------------------------------------------------------------------------- > > Reini Urban wrote: > >>add boolean option --temp-keep to pg_regress to keep the existing >>tmp_check installation, instead of overwriting it with a fresh make >>install. Useful to test minor modifications in the current tmp_check >>installation. >>-- >>Reini Urban >>http://xarch.tu-graz.ac.at/home/rurban/ > > >>*** src/test/regress/pg_regress.sh.orig Wed Sep 22 21:11:19 2004 >>--- src/test/regress/pg_regress.sh Fri Oct 15 12:38:00 2004 >>*************** >>*** 21,26 **** >>--- 21,27 ---- >> --schedule=FILE use test ordering schedule from FILE >> (may be used multiple times to concatenate) >> --temp-install[=DIR] create a temporary installation (in DIR) >>+ --temp-keep keep existing temporary installation >> >> Options for \`temp-install' mode: >> --top-builddir=DIR (relative) path to top level build directory >>*************** >>*** 90,95 **** >>--- 91,97 ---- >> unset debug >> unset top_builddir >> unset temp_install >>+ unset temp_keep >> unset multibyte >> >> dbname=regression >>*************** >>*** 127,132 **** >>--- 129,137 ---- >> --temp-install=*) >> temp_install=`expr "x$1" : "x--temp-install=\(.*\)"` >> shift;; >>+ --temp-keep) >>+ temp_keep=yes >>+ shift;; >> --max-connections=*) >> maxconnections=`expr "x$1" : "x--max-connections=\(.*\)"` >> shift;; >>*************** >>*** 358,389 **** >> ;; >> esac >> >>! if [ -d "$temp_install" ]; then >> message "removing existing temp installation" >> rm -rf "$temp_install" >>! fi >> >>! message "creating temporary installation" >>! if [ ! -d "$LOGDIR" ]; then >> mkdir -p "$LOGDIR" || { (exit 2); exit; } >>! fi >>! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 >> >>! if [ $? -ne 0 ] >>! then >> echo >> echo "$me: installation failed" >> echo "Examine $LOGDIR/install.log for the reason." >> echo >> (exit 2); exit >>! fi >> >>! # fix conversion shared objs path >>! conv=$datadir/conversion_create.sql >>! backup=$conv.bak >>! mv $conv $backup >>! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv >>! rm $backup >> >> message "initializing database system" >> [ "$debug" = yes ] && initdb_options='--debug' >>--- 363,398 ---- >> ;; >> esac >> >>! if [ "$temp_keep" = "yes" ]; then >>! message "keeping existing temp installation" >>! else >>! if [ -d "$temp_install" ]; then >> message "removing existing temp installation" >> rm -rf "$temp_install" >>! fi >> >>! message "creating temporary installation" >>! if [ ! -d "$LOGDIR" ]; then >> mkdir -p "$LOGDIR" || { (exit 2); exit; } >>! fi >>! $GMAKE -C "$top_builddir" DESTDIR="$temp_install/install" install with_perl=no with_python=no >"$LOGDIR/install.log"2>&1 >> >>! if [ $? -ne 0 ] >>! then >> echo >> echo "$me: installation failed" >> echo "Examine $LOGDIR/install.log for the reason." >> echo >> (exit 2); exit >>! fi >> >>! # fix conversion shared objs path >>! conv=$datadir/conversion_create.sql >>! backup=$conv.bak >>! mv $conv $backup >>! sed -e "s@\$libdir@$pkglibdir@g" $backup > $conv >>! rm $backup >>! fi # eof temp_keep >> >> message "initializing database system" >> [ "$debug" = yes ] && initdb_options='--debug' > > >>---------------------------(end of broadcast)--------------------------- >>TIP 9: the planner will ignore your desire to choose an index scan if your >> joining column's datatypes do not match > > -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Reini Urban wrote: > Bruce Momjian schrieb: > > Uh, why would someone use this option? > > after fixing a minor issue, not to wait for a full > de-install / install and test database loss. > > minor issues can be regression tests updates, or updated single binaries. Seems to be of too limited a usage. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reini Urban <rurban@x-ray.at> writes:
> Bruce Momjian schrieb:
>> Uh, why would someone use this option?
> after fixing a minor issue, not to wait for a full
> de-install / install and test database loss.
> minor issues can be regression tests updates, or updated single binaries.
Personally I find that "make installcheck" is the better way to handle
such scenarios. This assumes of course that you have a playpen
installation you're working with, but it's hard to imagine doing
development without one.
regards, tom lane
Dear Tom, > What I'd rather see is some effort spent on speeding up our "install" > script, maybe by allowing it to install multiple files per invocation. > The recent changes to force install-all-headers have caused a > serious degradation of "make install" performance, Yes, I agree. > and I think that's where the issue really needs to be solved. Improving the performance would require to fix the install script so that it can handle more than one argument at once, and/or use a more or less standard "install" program when available. It seems that there was a disagreement on these issues, so nothing was done in the end. I think we could try to use the same procedure as apache: - look for a standard BSD-install program (in configure) - have a multi-argument script as a replacement if none is found The opposition to this was because of portability concerns, which indeed require some attention. -- Fabien.
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Improving the performance would require to fix the install script so that
> it can handle more than one argument at once, and/or use a more or less
> standard "install" program when available.
We used to try to use the "standard" install program when available.
After sufficient bitter experience, we concluded that "standard" and
"install" are not words that should be used together.
regards, tom lane
Dear Tom, >> Improving the performance would require to fix the install script so that >> it can handle more than one argument at once, and/or use a more or less >> standard "install" program when available. > > We used to try to use the "standard" install program when available. > After sufficient bitter experience, we concluded that "standard" and > "install" are not words that should be used together. Ok. I trust you on that;-) Thus the only performance improvement I can see is to change the "install" script, for instance by considering the multi-argument apache version as a candidate replacement. This might require also to fix makefiles install target to take advantage of the fact. Also, it might require to deal with "extensions" of the postgres script somehow, if it has any such things. I might look into it as I'm somehow responsible for the "install-all-headers" new default, but I don't have much time right now. Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO schrieb: >>> Improving the performance would require to fix the install script so >>> that it can handle more than one argument at once, and/or use a more or less >>> standard "install" program when available. >> >> We used to try to use the "standard" install program when available. >> After sufficient bitter experience, we concluded that "standard" and >> "install" are not words that should be used together. > > > Ok. I trust you on that;-) > > Thus the only performance improvement I can see is to change the > "install" script, for instance by considering the multi-argument apache > version as a candidate replacement. > > This might require also to fix makefiles install target to take > advantage of the fact. > > Also, it might require to deal with "extensions" of the postgres script > somehow, if it has any such things. > > I might look into it as I'm somehow responsible for the > "install-all-headers" new default, but I don't have much time > right now. I don't believe that the install script is the only culprit, it's makefile target: all static libs, headers and all docs are not needed there. maybe add another install target: "install-regress" and collect only the needed binaries, shared libs, timezone and intl stuff. ah, even this is not needed. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Fabien COELHO wrote: > Thus the only performance improvement I can see is to change the > "install" script, for instance by considering the multi-argument > apache version as a candidate replacement. You can always override the default to use your own install program if you are really pressed for performance. (make install INSTALL=install or similar) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Dear Peter, >> Thus the only performance improvement I can see is to change the >> "install" script, for instance by considering the multi-argument >> apache version as a candidate replacement. > > You can always override the default to use your own install program if > you are really pressed for performance. (make install INSTALL=install > or similar) That simple idea alone seems to give a 25% cpu performance gain on my laptop for a "make check"... I'll try to find time to test the multi-arg install for further improvements anyway. Thanks! -- Fabien Coelho - coelho@cri.ensmp.fr