[PATCHES] 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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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
Re: [PATCHES] pg_regress --temp-keep
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.shFri 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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Cosmetic changes
It seems Peter has already applied many of the cleanups you suggested. If you have more, would you download the snapshot and send in a new patch? Thanks. --- Euler Taveira de Oliveira wrote: Hi, This small patch correct a hint style and change from multiple to single line comment because gettext seems not to like multiple line comments. Then we could see the translator: ... in po files too. = Euler Taveira de Oliveira euler[at]yahoo_com_br ___ Yahoo! Acesso Gr?tis - Internet r?pida e gr?tis. Instale o discador agora! http://br.acesso.yahoo.com/ Content-Description: cosmetic.diff [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [PATCH] 5 plperl patches
Patch applied. Thanks. --- Abhijit Menon-Sen wrote: I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv(undef,0) is the string undef, not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus eval_pv(key, 0) calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) -- ams [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_regress --temp-keep
Reini Urban [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] pg_regress --temp-keep
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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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 21
! 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 [EMAIL PROTECTED]@[EMAIL PROTECTED] $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/
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] pg_regress --temp-keep
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_regress --temp-keep
Reini Urban [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Slightly better testing for pg_ctl(1)'s -w...
Patch applied. Thanks.
I simplified your test and made the error message a #define that is now
used consistently in all places. Patch attached.
---
Sean Chittenden wrote:
pg_ctl(1)'s -w option works well if the default user can automatically
authenticate without any user intervention. The attached patch checks
the error message to see if it's asking for a password. The theory
being that if it's asking for a password, the backend is up. I'm not
entirely happy with the fact that I'm dependent on the error message
text, but I couldn't easily figure out a better way to test this via
libpq(3), so I'm not too unhappy... it's just not elegant. This patch
does not encompass all possible scenarios for the backend being up, but
CONNECTION_BAD being set in libpq(3). Regardless, it's a start and
hopefully someone can apply this. I also cleaned up a small memory
leak when a connection is bad (PGconn not being free(3)'ed). -sc
% pg_ctl -w start psql
waiting for postmaster to startdone
postmaster started
test=
[ Attachment, skipping... ]
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/pg_ctl/pg_ctl.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.38
diff -c -c -r1.38 pg_ctl.c
*** src/bin/pg_ctl/pg_ctl.c 15 Oct 2004 04:54:33 - 1.38
--- src/bin/pg_ctl/pg_ctl.c 16 Oct 2004 03:00:05 -
***
*** 364,370
charportstr[32];
char *p;
-
*portstr = '\0';
/* post_opts */
--- 364,369
***
*** 432,438
{
if ((conn = PQsetdbLogin(NULL, portstr, NULL, NULL,
template1, NULL,
NULL)) != NULL
! PQstatus(conn) == CONNECTION_OK)
{
PQfinish(conn);
success = true;
--- 431,439
{
if ((conn = PQsetdbLogin(NULL, portstr, NULL, NULL,
template1, NULL,
NULL)) != NULL
! (PQstatus(conn) == CONNECTION_OK ||
!(strcmp(PQerrorMessage(conn),
!PQnoPasswordSupplied) == 0)))
{
PQfinish(conn);
success = true;
Index: src/bin/pg_dump/pg_backup_db.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_db.c,v
retrieving revision 1.59
diff -c -c -r1.59 pg_backup_db.c
*** src/bin/pg_dump/pg_backup_db.c 1 Oct 2004 17:25:55 - 1.59
--- src/bin/pg_dump/pg_backup_db.c 16 Oct 2004 03:00:07 -
***
*** 168,174
if (PQstatus(newConn) == CONNECTION_BAD)
{
noPwd = (strcmp(PQerrorMessage(newConn),
! fe_sendauth: no password
supplied\n) == 0);
badPwd = (strncmp(PQerrorMessage(newConn),
Password authentication failed for user, 39)
== 0);
--- 168,174
if (PQstatus(newConn) == CONNECTION_BAD)
{
noPwd = (strcmp(PQerrorMessage(newConn),
! PQnoPasswordSupplied) == 0);
badPwd = (strncmp(PQerrorMessage(newConn),
Password authentication failed for user, 39)
== 0);
***
*** 249,255
die_horribly(AH, modulename, failed to connect to
database\n);
if (PQstatus(AH-connection) == CONNECTION_BAD
! strcmp(PQerrorMessage(AH-connection), fe_sendauth: no
password supplied\n) == 0
!feof(stdin))
{
PQfinish(AH-connection);
--- 249,255
die_horribly(AH, modulename, failed to connect to
database\n);
if (PQstatus(AH-connection) == CONNECTION_BAD
! strcmp(PQerrorMessage(AH-connection), PQnoPasswordSupplied)
== 0
!feof(stdin))
{
PQfinish(AH-connection);
Index: src/bin/pg_dump/pg_dumpall.c
Re: [PATCHES] libpq.dll on win32
Patch applied. Thanks.
I fixed a few merge conflicts.
---
Magnus Hagander wrote:
*** src/interfaces/libpq/fe-secure.c 28 Sep 2004 00:06:02
-1.54
--- src/interfaces/libpq/fe-secure.c 11 Oct 2004 19:50:22 -
***
*** 1201,1206
--- 1201,1212
return NULL;
return conn-ssl;
}
+ #else
+ void *
+ PQgetssl(PGconn *conn)
+ {
+return NULL;
+ }
#endif /* USE_SSL */
This seems like a good idea, but that particular approach to it will
draw an unprototyped-global-function warning on every non-SSL-enabled
compile ... please clean it up.
Oops. Updated patch attached.
Also, I count 3 *.def files to be fixed, not two.
Right. The Borland one, forgot all about that one. Included in attached
patch. Borland version not actually tested, though, since I don't have
Borland C..
(We really oughta
figure a way to generate them all from a single list file... can we
rely on sed(1) being available in all Windows build environments?)
Unfortunatly, no, we can't.
There are sed implementations available for win32, but they're not
installed by default. MingW and Cygwin of course ship with sed, but we
build libpq with MSVC and Borland as well...
The avaiable options to do it are just horrible. There is edlin, but it
can't be used for anything serious. Or there is the wonderful concept of
writing something in vbscript. But putting vbscript in there doesn't
seem like a very good option.
I like the idea of having it built automatically for the snapshots in
some way, and if you want to build it manually, you have to install
'sed'. I think that's a reasonable requirement.
Anyway. Here is the patch for this one. Not sure we want to muck around
with those build issues during beta considering they actually *work* now
(if a bit of extra work).
//Magnus
Content-Description: libpq_def.patch
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/Makefile.shlib
===
RCS file: /cvsroot/pgsql/src/Makefile.shlib,v
retrieving revision 1.85
diff -c -c -r1.85 Makefile.shlib
*** src/Makefile.shlib 15 Oct 2004 05:11:00 - 1.85
--- src/Makefile.shlib 16 Oct 2004 03:22:09 -
***
*** 31,36
--- 31,38
# DLLTOOL_DEFFLAGS Additional flags when creating the dll .def file
# DLLTOOL_LIBFLAGS Additional flags when creating the libmodule.a file
# DLLWRAP_FLAGS Additional flags to dllwrap
+ # DLL_DEFFILE Use pre-existing .def file instead of auto-generating
+ # one with all exports in it (win32 only).
#
# The module Makefile must also include
# $(top_builddir)/src/Makefile.global before including this file.
***
*** 306,314
--- 308,321
# Cygwin case
$(shlib) lib$(NAME).a: $(OBJS)
+ ifndef DLL_DEFFILE
$(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS)
$(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def
$(NAME).def $(OBJS) $(SHLIB_LINK)
$(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def
--output-lib lib$(NAME).a
+ else
+ $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def
$(DLL_DEFFILE) $(OBJS) $(SHLIB_LINK)
+ $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE)
--output-lib lib$(NAME).a
+ endif
endif # PORTNAME == cygwin
***
*** 316,324
--- 323,336
# win32 case
$(shlib) lib$(NAME).a: $(OBJS)
+ ifndef DLL_DEFFILE
$(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS)
$(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def
$(NAME).def $(OBJS) $(SHLIB_LINK)
$(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def
--output-lib lib$(NAME).a
+ else
+ $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def
$(DLL_DEFFILE) $(OBJS) $(SHLIB_LINK)
+ $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE)
--output-lib lib$(NAME).a
+ endif
endif # PORTNAME == win32
Index: src/interfaces/libpq/Makefile
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/Makefile,v
retrieving revision 1.117
diff -c -c -r1.117 Makefile
*** src/interfaces/libpq/Makefile 12 Oct 2004 04:48:36 -
Re: [PATCHES] [CYGWIN] postgresql 8.0 with cygwin - success
I did things a little differently. I #undef WIN32 after including
windows.h on Cygwin and kept the defines the same except for the use of
START. This makes things more consistent.
Applied.
---
Reini Urban wrote:
Marek Lewczuk schrieb:
Reini Urban wrote:
Bruce Momjian schrieb:
Great. Thanks. I was getting conflicting reports of Cygwin problems
before.
Not for me:
I found a problem with my pg_ctl patch (WIN32 is always defined in
cygwin when windows.h is included, and the START /B postmaster cmdline
doesn't work on cygwin). Patch will be posted soon.
Right. pg_ctl is not working - I didn't noticed that, because I use
postmaster instead pg_ctl. Below pg_ctl error:
$ pg_ctl start
START: not found
pg_ctl: could not start postmaster: exit code was 32512
Bruce:
was wondering about that use of START. What I think we will do
is to add a comment that including windows.h in that file defines WIN32
and have an #ifndef __CYGWIN__ in places that need it --- just let me
know.
Attached is my improved version: (just as you said)
* Fix previous pg_ctl patch (WIN32 is always defined in cygwin when
windows.h is included, and the START /B postmaster cmdline doesn't
work on cygwin.
You can safely ignore the patches of other two files, but these are my
remaining issues. (cygpg.dll just for overall conformancy).
I still have to test how it interacts with the eventlog if started as
service. (under different users)
However it should be better than the 7.x versions, which had lotta
problems with logfile file-permissions, because services are run as the
SYSTEM user.
But I finished now the plperl.sql regression tests and wait for
a clean regression suite to run through.
It would be great - I've just tried to run some plperl function, but no
luck (postgresql crashed).
:( as with 7.x
But first I have to find the SUBST problem (errno 140).
Then I will do some heavy IPC debugging with plperl.
(src/backend/port/ipc_test.c has to be fixed for old-style elog handling)
Then I have to do the mbregress tests (multibyte on cygwin? maybe newlib
has some remaining issues)
--
Reini Urban
--- postgresql-8.0.0cvs/src/bin/pg_ctl/pg_ctl.c.orig 2004-10-15 13:35:42.0
+0200
+++ postgresql-8.0.0cvs/src/bin/pg_ctl/pg_ctl.c 2004-10-15 18:17:30.09375
+0200
@@ -23,6 +23,9 @@
#if defined(__CYGWIN__)
#include windows.h
+#ifndef WIN32
+#define WIN32
+#endif
#endif
#ifndef HAVE_OPTRESET
@@ -99,7 +102,7 @@
static void do_status(void);
static void do_kill(pgpid_t pid);
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WIN32)
static bool pgwin32_IsInstalled(SC_HANDLE);
static char *pgwin32_CommandLine(bool);
static void pgwin32_doRegister();
@@ -120,7 +123,7 @@
static char conf_file[MAXPGPATH];
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WIN32)
static void
write_eventlog(int level, const char *line)
{
@@ -158,7 +161,7 @@
va_list ap;
va_start(ap, fmt);
-#if !defined(WIN32) !defined(__CYGWIN__)
+#if !defined(WIN32)
/* On Unix, we just fprintf to stderr */
vfprintf(stderr, fmt, ap);
#else
@@ -322,7 +325,7 @@
* http://dev.remotenetworktechnology.com/cmd/cmdfaq.htm
*/
if (log_file != NULL)
-#if !defined(WIN32) !defined(__CYGWIN__)
+#if !defined(WIN32) || defined(__CYGWIN__)
snprintf(cmd, MAXPGPATH, %s\%s\ %s%s \%s\ \%s\ 21 %s,
#else
snprintf(cmd, MAXPGPATH, %sSTART /B \\ \%s\ %s%s \%s\
\%s\ 21%s,
@@ -330,7 +333,7 @@
SYSTEMQUOTE, postgres_path, pgdata_opt, post_opts,
DEVNULL, log_file, SYSTEMQUOTE);
else
-#if !defined(WIN32) !defined(__CYGWIN__)
+#if !defined(WIN32) || defined(__CYGWIN__)
snprintf(cmd, MAXPGPATH, %s\%s\ %s%s \%s\ 21 %s,
#else
snprintf(cmd, MAXPGPATH, %sSTART /B \\ \%s\ %s%s \%s\ 21%s,
@@ -811,7 +814,7 @@
}
}
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WIN32)
static bool
pgwin32_IsInstalled(SC_HANDLE hSCM)
@@ -1089,14 +1092,14 @@
printf(_( %s reload [-D DATADIR] [-s]\n), progname);
printf(_( %s status [-D DATADIR]\n), progname);
printf(_( %s killSIGNALNAME PROCESSID\n), progname);
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WIN32)
printf(_( %s register [-N SERVICENAME] [-U USERNAME] [-P PASSWORD] [-D
DATADIR] [-w] [-o \OPTIONS\]\n), progname);
printf(_( %s unregister [-N SERVICENAME]\n), progname);
#endif
printf(_(Common options:\n));
printf(_( -D, --pgdata DATADIR location of the database storage area\n));
printf(_( -s, --silent only print errors, no informational messages\n));
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WIN32)
Re: [PATCHES] [HACKERS] plperl Safe restrictions
David Helgason wrote:
On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl.
Basically we allow the :default and :base_math set of operations (run
perldoc Opcode or see
http://www.perldoc.com/perl5.8.0/lib/Opcode.html for details of what
these mean). In particular, we do not allow calls to perl's builtin
sort, which is unpleasant, and on reviewing the list it seems to me
we could quite reasonably allow access to pack and unpack also. bless
and sprintf are also likely candidates for inclusion - I have not
finished reviewing the list, and would welcome advice from perl gurus
on this.
pack and unpack are unfortunately not safe. Very useful, but they
allow write/read access to random memory. It's really a shame perl
doesn't have a pragma to make them safe or have safe versions of them.
Bless should be OK, unless sensitive objects are provided to the
procedures.
A postgres question I don't know the answer to is whether allowing the
user to trigger a segfault is a security problem. If it isn't, several
opcodes may probably be allowed, including sort and sprintf. If it is,
well, you need only follow the perl5-porters list to know that there's
banal perl structures are continuously being found that will segfault
perl, some at compile time, other at runtime.
OK, based on this and some further thought, I have prepared the attached
patch which does the right thing, I think, both in terms of what we
allow and what we don't.
First, we tighten security by disallowing access to srand and IO
functions on existing filehandles (other IO ops are already disallowed).
The we relax the restrictions by allowing access to perl's sort, sprintf
and time routines. I decided against pack/unpack based on the above, and
also decided that I couldn't think of any case where bless would have
any practical use - although that might change later. I'm trying to keep
changes minimal here. I don't believe that time carries any
significant security implications, and I think the dangers from sort
and sprintf are not so great as to disallow them. They might cause a
SEGV in a pathological case, but that doesn't give the user access to
the machine - if they can login to postgres they can probably mount any
number of DOS attacks anyway.
To answer David's question, the man says this about trusted functions:
the TRUSTED flag should only be given for languages that do not allow
access to database server internals or the file system. I think the
changes I propose fit in with that statement.
The patch also does some other inconsequential tidying of overlong
lines, and removes some unnecessary ops in the unsafe case. These are
basically cosmetic - the only significant part is replacing this:
$PLContainer-permit(':base_math');
with this:
$PLContainer-permit(qw[:base_math !:base_io !srand sort sprintf time]);
I have tested and it appears to do the right thing, both for the things
excluded and those included.
cheers
andrew
Index: src/pl/plperl/plperl.c
===
RCS file: /home/cvsmirror/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.54
diff -c -r1.54 plperl.c
*** src/pl/plperl/plperl.c 7 Oct 2004 19:01:09 - 1.54
--- src/pl/plperl/plperl.c 15 Oct 2004 14:48:18 -
***
*** 250,266
static char *safe_ok =
use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
! $PLContainer-permit_only(':default');$PLContainer-permit(':base_math');
! $PLContainer-share(qw[elog spi_exec_query DEBUG LOG INFO NOTICE WARNING ERROR %SHARED ]);
sub ::mksafefunc { return $PLContainer-reval(qq[sub { $_[0] $_[1]}]); }
;
static char *safe_bad =
use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
! $PLContainer-permit_only(':default');$PLContainer-permit(':base_math');
! $PLContainer-share(qw[elog DEBUG LOG INFO NOTICE WARNING ERROR %SHARED ]);
sub ::mksafefunc { return $PLContainer-reval(qq[sub {
! elog(ERROR,'trusted perl functions disabled - please upgrade perl Safe module to at least 2.09');}]); }
;
SV *res;
--- 250,269
static char *safe_ok =
use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
! $PLContainer-permit_only(':default');
! $PLContainer-permit(qw[:base_math !:base_io !srand sort sprintf time]);
! $PLContainer-share(qw[elog spi_exec_query DEBUG LOG
! INFO NOTICE WARNING ERROR %SHARED ]);
sub ::mksafefunc { return $PLContainer-reval(qq[sub { $_[0] $_[1]}]); }
;
static char *safe_bad =
use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
! $PLContainer-permit_only(':default');
! $PLContainer-share(qw[elog ERROR ]);
sub ::mksafefunc { return $PLContainer-reval(qq[sub {
! elog(ERROR,'trusted perl functions disabled -
! please upgrade perl Safe module to at least 2.09');}]); }
