Re: [HACKERS] Fix for Perl 5.14
2011/4/23 Andrew Dunstan and...@dunslane.net: On 04/23/2011 03:02 AM, Alex Hunsaker wrote: Perl 5.14.0-RC1 came out a few days ago... There is a minor compile time error due to the API changing a bit: plperl.c:929:3: error: lvalue required as left operand of assignment This is due to GvCV() no longer returning an lvalue, instead they want us to use the new GvCV_set macro. (see http://search.cpan.org/~jesse/perl-5.14.0-RC1/pod/perldelta.pod#GvCV()_and_GvGP()_are_no_longer_lvalues) Unfortunately that macro is not available on older perls so the attached provides our own macro when GvCV_set is not defined. Tested with 5.14.0-rc1 and 5.12.3. The -head patch applies with fuzz to 9.0. The 8.4 patch applies clean to 8.4 and with fuzz to 8.3 and 8.2. How nice of them not to fix it in ppport.h. I thought this is exactly the sort of thing it's for. It's not so easy to convert foo = GvCV(bah); to a GvCV_set(foo, bar); with a ppport.h macro automatically. But yes, the backport GvCV_set = lvalue GvCV should be in ppport.h. It is not yet -- Reini Urban -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Enable SSPI on cygwin
Attached is my patch to enable SSPI on cygwin.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--- origsrc/postgresql-8.4.0/configure.in 2009-06-27 02:14:47.0 +0200
+++ src/postgresql-8.4.0/configure.in 2009-07-02 09:02:25.921875000 +0200
@@ -907,7 +907,11 @@ if test $with_gssapi = yes ; then
AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [],
[AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])])
else
-LIBS=$LIBS -lgssapi32
+if test $PORTNAME = cygwin; then
+ LIBS=$LIBS -lsecur32
+else
+ LIBS=$LIBS -lgssapi32
+fi
fi
fi
--- origsrc/postgresql-8.4.0/src/backend/libpq/auth.c 2009-06-25 13:30:08.0 +0200
+++ src/postgresql-8.4.0/src/backend/libpq/auth.c 2009-07-02 09:07:55.93750 +0200
@@ -159,6 +159,9 @@ static krb5_principal pg_krb5_server;
*
*/
#ifdef ENABLE_GSS
+#ifdef __CYGWIN__
+#define WIN32
+#endif
#if defined(HAVE_GSSAPI_H)
#include gssapi.h
#else
--- origsrc/postgresql-8.4.0/src/backend/postmaster/postmaster.c 2009-06-26 22:29:04.0 +0200
+++ src/postgresql-8.4.0/src/backend/postmaster/postmaster.c 2009-07-02 09:02:26.421875000 +0200
@@ -371,6 +371,9 @@ typedef struct
HANDLE PostmasterHandle;
#endif
+#endif
+#ifdef EXEC_BACKEND
+
static pid_t backend_forkexec(Port *port);
static pid_t internal_forkexec(int argc, char *argv[], Port *port);
@@ -442,6 +445,7 @@ static void ShmemBackendArrayAdd(Backend
static void ShmemBackendArrayRemove(Backend *bn);
#endif /* EXEC_BACKEND */
+
#define StartupDataBase() StartChildProcess(StartupProcess)
#define StartBackgroundWriter() StartChildProcess(BgWriterProcess)
#define StartWalWriter() StartChildProcess(WalWriterProcess)
@@ -1142,7 +1146,7 @@ checkDataDir(void)
*
* XXX can we safely enable this check on Windows?
*/
-#if !defined(WIN32) !defined(__CYGWIN__)
+#ifndef WIN32
if (stat_buf.st_uid != geteuid())
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
@@ -1164,7 +1168,7 @@ checkDataDir(void)
* be proper support for Unix-y file permissions. Need to think of a
* reasonable check to apply on Windows.
*/
-#if !defined(WIN32) !defined(__CYGWIN__)
+#ifndef WIN32
if (stat_buf.st_mode (S_IRWXG | S_IRWXO))
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
--- origsrc/postgresql-8.4.0/src/include/libpq/libpq-be.h 2009-06-11 16:49:11.0 +0200
+++ src/postgresql-8.4.0/src/include/libpq/libpq-be.h 2009-07-02 09:12:54.203125000 +0200
@@ -47,6 +47,9 @@
#ifdef ENABLE_SSPI
#define SECURITY_WIN32
+#ifdef __CYGWIN__
+#include windows.h
+#endif
#if defined(WIN32) !defined(WIN32_ONLY_COMPILER)
#include ntsecapi.h
#endif
--- origsrc/postgresql-8.4.0/src/include/libpq/libpq.h 2009-01-01 18:23:59.0 +0100
+++ src/postgresql-8.4.0/src/include/libpq/libpq.h 2009-07-02 09:02:26.703125000 +0200
@@ -20,6 +20,10 @@
#include lib/stringinfo.h
#include libpq/libpq-be.h
+#ifdef __CYGWIN__
+#undef WIN32
+#endif
+
/*
* PQArgBlock
* Information (pointer to array of this structure) required
--- origsrc/postgresql-8.4.0/src/include/miscadmin.h 2009-06-11 16:49:08.0 +0200
+++ src/postgresql-8.4.0/src/include/miscadmin.h 2009-07-02 09:02:26.765625000 +0200
@@ -78,7 +78,7 @@ extern PGDLLIMPORT volatile uint32 CritS
/* in tcop/postgres.c */
extern void ProcessInterrupts(void);
-#ifndef WIN32
+#if !defined(WIN32) || defined(__CYGWIN__)
#define CHECK_FOR_INTERRUPTS() \
do { \
--- origsrc/postgresql-8.4.0/src/include/port/cygwin.h 2007-07-25 14:22:53.0 +0200
+++ src/postgresql-8.4.0/src/include/port/cygwin.h 2009-07-02 09:02:26.84375 +0200
@@ -19,3 +19,10 @@
#define PGDLLIMPORT __declspec (dllimport)
#endif
+
+/*
+ * Always build with SSPI support. Keep it as a #define in case
+ * we want a switch to disable it sometime in the future.
+ */
+#define ENABLE_SSPI 1
+
--- origsrc/postgresql-8.4.0/src/interfaces/libpq/Makefile 2009-01-05 10:27:19.0 +0100
+++ src/postgresql-8.4.0/src/interfaces/libpq/Makefile 2009-07-20 13:18:59.296875000 +0200
@@ -63,6 +63,9 @@ endif
ifeq ($(PORTNAME), win32)
SHLIB_LINK += -lshfolder -lwsock32 -lws2_32 -lsecur32 $(filter -leay32 -lssleay32 -lcomerr32 -lkrb5_32, $(LIBS))
endif
+ifeq ($(PORTNAME), cygwin)
+SHLIB_LINK += -lsecur32
+endif
SHLIB_EXPORTS = exports.txt
--- origsrc/postgresql-8.4.0/src/interfaces/libpq/fe-connect.c 2009-06-11 16:49:13.0 +0200
+++ src/postgresql-8.4.0/src/interfaces/libpq/fe-connect.c 2009-07-20 13:14:11.21875 +0200
@@ -22,12 +22,16 @@
#include time.h
#include unistd.h
+#ifdef __CYGWIN__
+#undef WIN32
+#endif
+
#include libpq-fe.h
#include libpq-int.h
#include fe-auth.h
#include pg_config_paths.h
-#ifdef WIN32
+#if defined(WIN32) !defined(__CYGWIN__)
#include win32.h
#ifdef _WIN32_IE
#undef _WIN32_IE
--- origsrc
Re: [HACKERS] stat() vs cygwin
Bruce Momjian schrieb: Andrew Dunstan wrote: Bruce Momjian wrote: Andrew Dunstan wrote: Alvaro Herrera wrote: Andrew Dunstan wrote: I'm confused. There is a Cygwin member of buildfarm, working quite happily. Can you point me to the exact patch in question, please? I thought we resolved the matter of stat() ages ago. http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at That patch is NOT about $subject. In fact, if you read that whole thread you will see here http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I conducted a test on Cygwin and found it was not suffering from the problem we fixed on WIN32. AFAICT Reini's patch is about fixing OpenSSL and possibly some other options on Cygwin. It was rejected because it had other problems, but is not indicative of a fundamental problem on Cygwin. There is no reason I am aware of that we should declare Cygwin no longer supported, no matter how much its continued existence apparently annoys a few people :-) . Oh, good, thanks for clearing that up. So should we just document that OpenSSL doesn't work on Cygwin and call this item closed? This item should be closed. We should see if Reini can submit an acceptable patch for OpenSSL. I have documented that OpenSSL is not supported for Cygwin. Excuse me? openssl works fine on cygwin, even without the testing patch which was attached. This patch only tried to optimize openssl socket handling equivalent to WIN32. Please revert that documentation. The current configure args of the official postgresql packages are: --enable-nls --with-openssl --with-perl --with-python --with-ldap The problem is just that SSPI auth does not compile on cygwin. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] stat() vs cygwin
Dave Page schrieb:
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
Yes.
As in the cygwin build does build. Nobody really has verified if the fix
is needed there. But frankly, if you are likely to care about the
effects of this issue, you won't be running cygwin anyway. It's mostly a
dead platform for postgresql anyway, AFAICS we only keep it building for
legacy compatibility. Once it starts taking lots of resources to keep
building (which it doesn't now), I think we should just drop it instead...
Dead is interesting. We see a lot of cygwin users having postgresql
installed.
FWIW, the most recent packages from Cygwin themselves are 8.2.5.
Update: 8.2.9 is latest.
8.3.x not because the new SSPI doesn't work yet.
currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java
--with-ossp-uuid --with-ldap
(but ldap works okay with 8.2.9)
currently testing is: --enable-nls --with-CXX --with-openssl --with-perl
--with-python --with-libxml --with-libxslt
current cygwin patch in testing is attached.
--
Reini Urban
postgresql cygwin maintainer
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x 'postgresql-8.2.0-1.cygport~' -x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x 'postgresql-8.2.9-1.cygport~' -x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x 'postgresql7.4-7.4.13-1.cygport~' -x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/auth.c src/postgresql-8.3.3/src/backend/libpq/auth.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/auth.c 2008-02-08 17:58:46.0 +
+++ src/postgresql-8.3.3/src/backend/libpq/auth.c 2008-06-28 08:27:03.53125 +
@@ -32,6 +32,9 @@
#include libpq/pqformat.h
#include storage/ipc.h
+#ifdef __CYGWIN__
+#define WIN32
+#endif
static void sendAuthRequest(Port *port, AuthRequest areq);
static void auth_failed(Port *port, int status);
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x 'postgresql-8.2.0-1.cygport~' -x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x 'postgresql-8.2.9-1.cygport~' -x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x 'postgresql7.4-7.4.13-1.cygport~' -x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c src/postgresql-8.3.3/src/backend/libpq/be-secure.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-01-01 19:45:49.0 +
+++ src/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-06-28 08:27:03.546875000 +
@@ -280,9 +280,26 @@
case SSL_ERROR_WANT_WRITE:
#ifdef WIN32
pgwin32_waitforsinglesocket(SSL_get_fd(port-ssl),
- (err == SSL_ERROR_WANT_READ) ?
- FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
- INFINITE);
+ (err == SSL_ERROR_WANT_READ) ?
+ FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
+ INFINITE);
+#elif defined(__CYGWIN__)
+/* be nicer on cygwin also */
+{
+fd_set rset;
+int sel_res;
+struct timeval tv;
+FD_ZERO(rset);
+FD_SET(SSL_get_fd(port-ssl), rset);
+tv.tv_sec = 0;
+tv.tv_usec = 50;
+sel_res = select(FD_SETSIZE,
+ (err
Re: [HACKERS] stat() vs cygwin
Magnus Hagander schrieb: Reini Urban wrote: Dave Page schrieb: On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote: Yes. As in the cygwin build does build. Nobody really has verified if the fix is needed there. But frankly, if you are likely to care about the effects of this issue, you won't be running cygwin anyway. It's mostly a dead platform for postgresql anyway, AFAICS we only keep it building for legacy compatibility. Once it starts taking lots of resources to keep building (which it doesn't now), I think we should just drop it instead... Dead is interesting. We see a lot of cygwin users having postgresql installed. Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. FWIW, the most recent packages from Cygwin themselves are 8.2.5. Update: 8.2.9 is latest. Good! 8.3.x not because the new SSPI doesn't work yet. currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java --with-ossp-uuid --with-ldap (but ldap works okay with 8.2.9) currently testing is: --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt current cygwin patch in testing is attached. I assume this is a WIP and not actually for application, right? Please look it over because it contains a number of pure-whitespace changes that make it harder to read, and that will just end up being undone by pgindent at a later date anyway. Sure. This is just the current status of my patch (still from 8.3beta2), nothing to actually submit. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. SSPI has some direct winapi calls to libsecure32 which are simpliest to declare by this cygwin == WIN32 declaration in the backend. For the client libpq this is not so easy, I still have troubles seperating this. There's also a number of: -#ifndef·WIN32 +#if·!defined(WIN32)·||·defined(__CYGWIN__) If I read that right, it shouldn't be necessary as long as the WIN32 define is not set on CYGWIN? This is only for the special case cygwin == WIN32. Just to be sure while testing I wrote it this way. And finally: -VALUE·OriginalFilename,·libpq.dll\0 +VALUE·OriginalFilename,·cygpq.dll\0 This obviously has to be done another way, because that change will affect the win32 platform as well... Sure :) This is only vendor private. -- Reini -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] stat() vs cygwin
Andrew Dunstan schrieb: Magnus Hagander wrote: Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. AIUI, only the gssapi stuff is broken. Most users are not likely to want it on Cygwin I should think. (And plenty of distros are still on 8.2 and earlier, anyway). Well, native windows users is a very nice to have. Actually a killer feature. What would be nice would be for Reini to set up a Cygwin buildfarm member that uses all the switches that the Cygwin distro wants to use. Without ENABLE_SSPI I just need --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt --with-ldap and these build out of the box. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. Right. We have had significant grief from this in the past, and don't need to return there. If we need it to get correct behaviour from some header file, then it needs to be heavily commented and localised. But I bet there are other ways to get the right result - that's what we've tended to find in the past. Ok, I copy then the required lines from WIN32. This was the shortest patch I could come up with and it worked nice for the auth backend, with SSPI enabled. -- Reini -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How large file is really large - pathconf results
Zdenek Kotala schrieb: Regarding to discussion about large segment size of table files a test pathconf function (see http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html). You can see output there: _PC_FILESIZEBITS - 3rd column _PC_LINK_MAX - 4th column _PC_NAME_MAX - 5th column _PC_PATH_MAX - 6th column Solaris NevadaZFS64-12551024 UFS41327672551024 FAT33181024 NFS41327672551024 Solaris 8UFS41327672551024 NFS40327672551024 Centos4(2.6.11)EXT364320002554096 XFS6421474836472554096 Mac OSX leopardHFS+64327672551024 cygwin 1.5 on NTFS. But 1.7 will a have much larger _PC_PATH_MAX. _PC_FILESIZEBITS undefined _PC_LINK_MAX = 8 _PC_NAME_MAX = 260 _PC_PATH_MAX = 257 So this is really bad. -- Reini Urban -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] float8 regression failure (HEAD, cygwin)
Adrian Maier schrieb:
Hello,
While setting up a buildfarm installation for cygwin, I've
uncountered the following
regression failure :
float8 ... FAILED
== pgsql.3132/src/test/regress/regression.diffs
*** ./expected/float8-small-is-zero.outTue Jul 18 09:24:52 2006
--- ./results/float8.outTue Jul 18 09:53:42 2006
***
*** 13,29
SELECT '-10e400'::float8;
ERROR: -10e400 is out of range for type double precision
SELECT '10e-400'::float8;
! float8
!
! 0
! (1 row)
!
SELECT '-10e-400'::float8;
! float8
!
! -0
! (1 row)
!
-- bad input
INSERT INTO FLOAT8_TBL(f1) VALUES ('');
ERROR: invalid input syntax for type double precision:
--- 13,21
SELECT '-10e400'::float8;
ERROR: -10e400 is out of range for type double precision
SELECT '10e-400'::float8;
! ERROR: 10e-400 is out of range for type double precision
SELECT '-10e-400'::float8;
! ERROR: -10e-400 is out of range for type double precision
-- bad input
INSERT INTO FLOAT8_TBL(f1) VALUES ('');
ERROR: invalid input syntax for type double precision:
***
*** 377,383
--- 369,377
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
ERROR: -10e400 is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR: 10e-400 is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR: -10e-400 is out of range for type double precision
-- maintain external table consistency across platforms
-- delete all values and reinsert well-behaved ones
DELETE FROM FLOAT8_TBL;
=
This happening on cygwin 1.5.20 (running on top of winXP), gcc 3.4.4.
The entire check.log can be found here :
http://www.newsoftcontrol.ro/~am/pgfarm/check.log
The other logs generated by the buildfarm can be found here:
http://www.newsoftcontrol.ro/~am/pgfarm/
Thanks,
Which postgresql version?
Can we have a regular cygwin error report please mailed to cygwin at
cygwin.com please. See http://cygwin.com/problems.html (cygcheck -s -v
-r cygcheck.out)
Looks like a strtod() newlib feature, but I haven't inspected closely.
http://sources.redhat.com/ml/newlib/2006/msg00020.html
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
Does it look the same on redhat fedora?
Our buildfarm doesn't have these issues,
this runs gcc-3.3.3 and gcc-3.4.4
The problem I see is that float8in() in
src/backend/utils/adt/float.c checks only for -Infinity and not -inf
as returned by newlib:
pg_strncasecmp(num, -Infinity, 9) == 0
Can you test this?
$ cat test-strtod.c
#include stdlib.h
#include stdio.h
#include errno.h
#include float.h
double d;
char *tail;
int main() {
errno = 0;
d = strtod(-10e400, tail);
printf(double: %f, errno: %d, tail: '%s', isinf: %d, fabs: %f,
infmax: %d ,
d, errno, tail, isinf(d), fabs(d), fabs(d) DBL_MAX ? 1 : 0);
}
$ gcc test-strtod.c; ./a
double: -inf, errno: 34, tail: '', isinf: 1, fabs: inf, infmax: 1
--
Reini Urban - postgresql-cygwin maintainer
http://phpwiki.org/ http://murbreak.at/
http://helsinki.at/ http://spacemovie.mur.at/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] compiling source code!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
sibel karaasma schrieb: Hi I'm a new postgresql user. I wrote ACO (ant colony optimazition) and want to replace it with GEQO in postres/src/backend/optimizer but I don't know how to compile and run the source code :( I installed postgresql-8.1.3 and cygwin but I can not use them to compile the source code. I want to compare GEQO and ACO optimizers performance using a small database Can you help me??? download the src package via cygwin.com/setup.exe and check out the buildscript to see the used configure parameters and get all the dependencies right. -- Reini ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-hackers-win32] Time to close pgsql-cygwin?
Magnus Hagander schrieb: It occurs to me that there is no longer any great need to have a separate hackers list for win32 development. Perhaps we should close it down now and keep all development on -hackers? I also think this is a good idea. The number of win32 only issues of -hacker level is significantly smaller now, and having to bounce people between the lists can be kind of annoying... I believe we should close pgsql-cygwin also. The cygwin users should ask at the official cygwin list as described in the README and CYGWIN announcements, not at the pgsql-cygwin list. Most problems are cygwin specific, others are carried in the FAQ_README and the seperate /usr/share/doc/Cygwin/postgresql-x.x.x.README If so, I'll write a documentation patch. -- Reini Urban http://phpwiki.org/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Cygwin - make check broken
Andrew Dunstan schrieb: Tom Lane wrote: Andrew Dunstan writes: Marko Kreen wrote: On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote: Couple thoughts here --- one, someone upthread suggested cyg$(NAME)$(DLSUFFIX as the proper value for shlib. .exe's in different directories than .dll's but all in PATH. Especially DLLs in the system directory. Anyway, I see no point *not* to observe the platform's convention. I just tested it and make check worked fine. OK, applied with the cyg prefix. When you get a chance, would you see if the SHLIB_LINK += $(LIBS) bit is still needed? I commented it out of the Cygwin stanza and all seemed fine - contrib built and passed installcheck quite happily. Ok, thanks a lot! This was my hack. The magic cyg prefix makes it easier for libtool and the gcc linker to detect dll's for import libraries, and also makes it easier to mix both (cygwin vs. mingw and msvc) client libs and have both of them in the path. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Cygwin - make check broken
Rocco Altier schrieb: It looks like when we changed regress/GNUmakefile to pull rules from Makefile.shlib, cygwin got broken in the process. The problem is that regess.dll ends up being a symlink back to itself, because we do a: $(NAME)$(DLSUFFIX): $(shlib) rm -f $(NAME)$(DLSUFFIX) $(LN_S) $(shlib) $(NAME)$(DLSUFFIX) And from Makefile.shlib (for cygwin) ifeq ($(PORTNAME), cygwin) shlib = $(NAME)$(DLSUFFIX) Thus regress.dll gets unhappy :-( I don't know enough about the rest of the way the cygwin port is put together, but it seems that the other platforms all have shlib=lib$(NAME)... For cygwin the normal rule is cyg$(NAME)$(DLSUFFIX), but the postgresql maintainers refused to changed the prefix for 8.0 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] minor windows cygwin regression failures on stable
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What has changed in the last 3 weeks is that I refreshed my Cygwin installation, I think when I was wrestling with the NLS thing. If nothing in postgres has changed in this area I assume that platform changes account for the regression. Sounds that way to me too, but it's disturbing. One would say they broke their scheduler :-(. Possibly you should try to stir up some interest among the Cygwin hackers in looking into this. I'd like somebody else to report the same phenomenon first. Reini? Why plperl is broken I cannot say yet. I still have the same general IPC permission problem since about beta3. Only very few cygwin hackers have this also. I only got confirmation that the problem is in postgresql, not in cygwin. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] Some things I like to pick from the TODO list ...
Alvaro Herrera schrieb: On Tue, Jan 18, 2005 at 08:15:10PM +0100, Matthias Schmidt wrote: 1) Allow limits on per-db/user connections Sounds hard to do: what limits? CPU, disk? Note that a typical server limit, the load average, will not be portable. There's no WIN32 solution yet. The CPU load is also not really easy to port, but there exist solutions. But I guess you are only talking about restricting client connections, which is easy enough. -- Reini Urban ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm improvements
Andrew Dunstan schrieb: Reini Urban wrote: What I also miss is the successful output of the make test step. Something like the Log in Details, just behind an additional request. Config = Log Link to Details Without those details one doesn't trust the presented result. He might think that only the build was successful, and not the make test step also. People I redirect to this page from other projects, not reading the status pages everyday. That would actually be a substantial change in the way it works. Basically, it sends the log of the step that failed. That preserves bandwidth and doesn't clog the database with success cases. These logs are not inconsiderable - I just checked on the canonical system and for the last successful run they were 640Kb. I was originally given this (virtual) server on the basis of my assurance that the bandwidth and database requirements would be very modest, so I'm inclined to keep to that. Sure. Convinced. Regarding your last sentence - the intended prime users are the postgresql hackers. If it had a vastly more general audience I would have produced something a good less spartan in style. I'm not quite sure why you're redirecting people to the status pages from other projects. This is not the official list of supported platforms, and is not intended as a substitute for it. Perhaps we could put a statement at the top of the details page saying what steps have succeeded (which we could infer from the result). Of course, if people don't want to believe it then they won't - having logs should not make believing it any easier - faking the logs would be quite trivial. FYI here's what happens during a run - a status of OK means that *all* of this has run successfully: [EMAIL PROTECTED] buildfarm]$ ./run_build.pl --verbose checking out source ... checking if build run needed ... copying source to pgsql.3034 ... running configure ... running make ... running make check ... running make contrib ... running make install ... setting up db cluster ... starting db ... running make installcheck ... restarting db ... running make contrib install ... running make contrib installcheck ... stopping db ... OK Printing this output would be enough for me, and other manager types. All the buildfarm members are known, by the way, and every status report is signed with a SHA1 signature. We don't just accept anonymous reports. In many cases I know these people from previous electronic interaction, via email and/or IRC. That, more than the presence of success logs, should give you some confidence in the results, I hope. -- Reini Urban ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] buildfarm improvements
Andrew Dunstan schrieb: I have implemented several requested improvements, which I hope will prove useful. Since this whole piece of work exists for the benefit of the pg developers, I'm posting some info here. The latest version includes these features: . the log page shows the system type near the top OS/Compiler/Architecture . the log page shows the script configuration data (other than the password) and including the script version number . the changed files list(s) on the log page include CVS revision numbers. An example showing all these can be seen at http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dogdt=2004-12-17%2021:06:01 Constructive comments welcome as always. Good. What I also miss is the successful output of the make test step. Something like the Log in Details, just behind an additional request. Config = Log Link to Details Without those details one doesn't trust the presented result. He might think that only the build was successful, and not the make test step also. People I redirect to this page from other projects, not reading the status pages everyday. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] src/timezone/pgtz __imp__my_exec_path
postgresql-cygwin is working fine. See the testfarm. Just cygwin itself, cygserver - the IPC daemon - has problems. On msgctl(IPC_INFO) the internal msg buffer struct msqid_ds *buf is allocated at a non-writable area, IsBadWritePtr() fails. I suspect it's a new gcc-3.4 feature, but haven't found the problem yet. gcc-3.3 fails also. (these don't have dwarf-2 support yet, just sjlj. cygwin itself is c++ and uses exceptions heavily.) It works for most users out there, but not for me, this is why I didn't did a proper beta5 cygwin release yet. A pity that no one else can confirm my cygserver problems yet. And I got beta4 on a fairly busy server working only with max-connection=2, not more. Bruce Momjian schrieb: Is Cygwin now working properly in CVS and beta5? I assume so. --- Magnus Hagander wrote: beta4 - cygwin: postgres.exe fails to build, because __imp__my_exec_path from src/timezone/pgtz.o cannot be resolved. previously it was not imported. This could be related to the patch that went in last weekend to fix compiles on Win32. DLLIMPORT was added to the header. If the Makefile did not change, then that is your problem - that patch changed botht he makefile and the header. See http://archives.postgresql.org/pgsql-committers/2004-10/msg00321.php Does CYGWIN perhaps need the same Makefile patch? You only patched your Makefile.win32, not Makefile.cygwin. That's it. It builds fine now. Please add also ifneq (,$(findstring timezone,$(subdir))) override CPPFLAGS+= -DBUILDING_DLL endif to the Makefile.cygwin. Without it doesn't break just contrib/tsearch, it even breaks cygwin postmaster. Soudns reasonable. Maybe all win32.mak and bcc32.mak must also be checked. Does anybody do the msvc/borland suites? Not affected. Only the frontend can be compiled with those, and this is a backend change. -- I'm using MozTweak addon, and you? MozTweak: http://www.MozillaPL.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta5 in ~4 hours ...
Marc G. Fournier schrieb: Just as a heads up, I'm going to roll it in about 4hrs (~02:00GMT) ... I checked a couple of mirrors this morning and only the swedish one got it so far. (timestamps 03:24 - 03:36) Maybe it would be better next time to upload it before 0:00 GMT -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta5 Scheduale
Marc G. Fournier schrieb: Just a quick note, since we obviously passed the previous date we were aiming for ... we're aiming for Sunday evening to roll Beta5 ... all the major stuff that we felt were outstanding have been committed, and a *large* # of the smaller patches, but Bruce is working through his list and would like to get as many in as possible before Beta5 ... I'll also roll out a new cygwin beta5 test package for wider test audience. The last I did was between beta2 and beta3. -- Fear is that little darkroom where negatives are developed. (Michael Pritchard) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] are there any cons to linking libstdc++ with postgresql?
Palle Girgensohn schrieb: I'm not a linking guru... Is there a penalty for setting LDFLAGS+= -lstdc++ when building postgresql? Postgis includes a bunch of useful functions for manipulating spatial data. Some of them are provided by geos, a separate c++ library, with postgis providing wrappers. According to postgis docs, postgresql _must_ be configured with LDFLAGS containing -lstdc++ for this to work. I can confirm this. The postgis port provides the WITH_GEOS tunable, but it has no effect unless the above adjustment is made to postgresql. The port makes no mention of this. Is there a penalty in just leaving LDFLAGS+= -lstdc++ in the postgresql port Makefile? Bad idea? What do you think? I'd rather use a libgeos wrapper using just extern C entry points, not the C++ mangled entries. Haven't checked yet how much trouble this may cause on geos, and if it will work with the exceptions. And if a simple .def with aliases would be enough. libgeos is huge. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Minor problem with Makefile.shlib
Thomas Hallgren schrieb: I have a minor issue with Makefile.shlib. Compiling with win32 it spits out these warnings (the same is true for Cygwin) Makefile.shlib:327: warning: overriding commands for target `libpljava.a' Makefile.shlib:262: warning: ignoring old commands for target `libpljava.a' As it turns out, the rule to make the lib$(NAME).a actually has commands defined in multiple places when Cygwin or win32 is used. In global scope we find the following at line 260: lib$(NAME).a: $(OBJS) ifdef MK_NO_LORDER $(LINK.static) $@ $^ else $(LINK.static) $@ `$(LORDER) $^ | tsort` endif $(RANLIB) $@ Then, further down and win32 specific on line 325: $(shlib) lib$(NAME).a: $(OBJS) ^ This is wrong. Those static import libs should be called lib$(NAME).dll.a and are a completely different beast than the pure static lib from above. But it will only bite when ever a module wants both, static AND shared libs. 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 As I said, it's is no big issue since it just results in two warnings. -- Man is by nature a political animal. (Aristotle, Politics) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] latest cygwin build failure
Andrew Dunstan schrieb:
with CVS tip in contrib/spi:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -DREFINT_VERBOSE -I. -I../../src/include -c -o
timetravel.o timetravel.c
dlltool --export-all --output-def timetravel.def timetravel.o
dllwrap -o timetravel.dll --def timetravel.def timetravel.o
../../src/utils/dllinit.o -L../../src/backend -lpostgres
timetravel.o(.text+0x10cb):timetravel.c: undefined reference to
`_pg_strcasecmp'
collect2: ld returned 1 exit status
dllwrap: gcc exited with status 1
make[1]: *** [timetravel.dll] Error 1
rm refint.o autoinc.o timetravel.o moddatetime.o insert_username.o
make[1]: Leaving directory
`/home/adunstan/pgbf/root/HEAD/pgsql.blurfl/contrib/spi'
This was addressed in my patch I sent.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Index: contrib/spi/Makefile
===
RCS file: /projects/cvsroot/pgsql/contrib/spi/Makefile,v
retrieving revision 1.24
diff -u -b -r1.24 Makefile
--- contrib/spi/Makefile20 Aug 2004 20:13:08 - 1.24
+++ contrib/spi/Makefile8 Nov 2004 05:34:53 -
@@ -1,4 +1,4 @@
-# $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.24 2004/08/20 20:13:08 momjian
Exp $
+# $PostgreSQL: pgsql-server/contrib/spi/Makefile,v 1.24 2004/08/20 20:13:08
momjian Exp $
MODULES = autoinc insert_username moddatetime refint timetravel
DATA_built = $(addsuffix .sql, $(MODULES))
@@ -17,3 +17,5 @@
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
+
+SHLIB_LINK += -L$(top_builddir)/src/port -lpgport
Index: src/bin/pg_ctl/pg_ctl.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.45
diff -u -b -r1.45 pg_ctl.c
--- src/bin/pg_ctl/pg_ctl.c 4 Nov 2004 22:25:12 - 1.45
+++ src/bin/pg_ctl/pg_ctl.c 8 Nov 2004 05:35:21 -
@@ -22,6 +22,7 @@
#include getopt_long.h
#if defined(__CYGWIN__)
+#include sys/cygwin.h
#include windows.h
/* Cygwin defines WIN32 in windows.h, but we don't want it. */
#undef WIN32
@@ -820,6 +821,9 @@
{
static char cmdLine[MAXPGPATH];
int ret;
+#ifdef __CYGWIN__
+ static char buf[MAXPGPATH];
+#endif
if (registration)
{
@@ -839,6 +843,11 @@
exit(1);
}
}
+#ifdef __CYGWIN__
+ /* need to convert to windows path */
+ cygwin_conv_to_full_win32_path (cmdLine, buf);
+ strcpy(cmdLine, buf);
+#endif
if (registration)
{
Index: src/interfaces/libpq/Makefile
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v
retrieving revision 1.120
diff -u -b -r1.120 Makefile
--- src/interfaces/libpq/Makefile 16 Oct 2004 22:52:49 - 1.120
+++ src/interfaces/libpq/Makefile 8 Nov 2004 05:35:28 -
@@ -31,6 +31,10 @@
md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o \
$(filter crypt.o getaddrinfo.o inet_aton.o open.o snprintf.o
strerror.o, $(LIBOBJS))
+ifeq ($(PORTNAME), cygwin)
+override shlib = cyg$(NAME)$(DLSUFFIX)
+endif
+
ifeq ($(PORTNAME), win32)
OBJS += win32.o libpqrc.o
libpqrc.o : libpq.rc
Index: src/template/cygwin
===
RCS file: /projects/cvsroot/pgsql/src/template/cygwin,v
retrieving revision 1.4
diff -u -b -r1.4 cygwin
--- src/template/cygwin 9 Oct 2003 14:40:36 - 1.4
+++ src/template/cygwin 8 Nov 2004 06:59:51 -
@@ -1 +1,6 @@
SRCH_LIB=/usr/local/lib
+# This is required to link pg_dump because it finds pg_toupper() in
+# libpq and pgport
+LDFLAGS=-Wl,--allow-multiple-definition -Wl,--enable-auto-import
+# --enable-auto-import gets rid of a diagnostics linker message
+LDFLAGS_SL=-Wl,--enable-auto-import
Index: src/include/port.h
===
RCS file: /projects/cvsroot/pgsql/src/include/port.h,v
retrieving revision 1.65
diff -u -b -r1.65 port.h
--- src/include/port.h 6 Nov 2004 01:16:14 - 1.65
+++ src/include/port.h 8 Nov 2004 07:00:42 -
@@ -72,12 +72,17 @@
extern int find_other_exec(const char *argv0, const char *target,
const char *versionstr, char *retpath);
-#if defined(WIN32) || defined(__CYGWIN__)
-#define EXE .exe
-#define DEVNULL nul
+#if defined(WIN32) !defined(__CYGWIN__)
+# define EXE .exe
+# define DEVNULL nul
#else
-#define EXE
-#define DEVNULL /dev/null
+# if defined(__CYGWIN__)
+# define EXE .exe
+# define DEVNULL /dev/null
+# else
+# define EXE
+# define DEVNULL /dev/null
+# endif
#endif
/*
@@ -89,13 +94,13 @@
* See the Notes section about quotes at:
* http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM
*/
-#ifdef WIN32
+#if defined(WIN32
Re: [HACKERS] cygwin build failure
Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. #ifdef BUILDING_DLL # ifndef __GNUC__ # define __DLL_IMPORT __declspec(dllimport) # else # define __DLL_IMPORT __attribute__((dllimport)) extern # endif #else # define __DLL_IMPORT #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cygwin build failure
Reini Urban schrieb: Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] use of IDE's an tools
Gevik Babakhani schrieb: Would you please be so kind to help me with some pointers about which IDEs you use in order to compile and take a look at the sources? Any comment is appreciated. my windows IDE: cmd.exe, 4nt.exe or rxvt.exe terms with bash or cmd as shells, XEmacs, TotalCommander coLinux to crosscheck on a linux image (faster than vmware, in fact much faster than windows) compile: make + gcc, or nmake + msvc cl.exe look at the sources: XEmacs or TotalCommander f3 or $ less src -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cygwin build failure
Bruce Momjian schrieb: OK, Andrew found the proper flag so Cygwin and MinGW linking will find the first matching library symbol (like Unix) and not error out because of multiple definitions. I have applied the following patch and removed the pg_dump Makefile hack we had before. --- Bruce Momjian wrote: I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v retrieving revision 1.57 diff -c -c -r1.57 Makefile *** src/bin/pg_dump/Makefile 7 Oct 2004 13:45:48 - 1.57 --- src/bin/pg_dump/Makefile 8 Nov 2004 04:56:52 - *** *** 22,33 EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o - # Not sure why MinGW needs this but it prevents a link failure - # of duplicate definitions for pg_tolower(). 2004-10-06 - ifeq ($(PORTNAME), win32) - EXTRA_OBJS += $(top_builddir)/src/port/exec.o - endif - all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore pg_dumpall pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(libpq_builddir)/libpq.a --- 22,27 Index: src/template/cygwin === RCS file: /cvsroot/pgsql/src/template/cygwin,v retrieving revision 1.4 diff -c -c -r1.4 cygwin *** src/template/cygwin 9 Oct 2003 14:40:36 - 1.4 --- src/template/cygwin 8 Nov 2004 04:56:55 - *** *** 1 --- 1,5 SRCH_LIB=/usr/local/lib + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + Index: src/template/win32 === RCS file: /cvsroot/pgsql/src/template/win32,v retrieving revision 1.2 diff -c -c -r1.2 win32 *** src/template/win32 9 Oct 2003 03:20:34 - 1.2 --- src/template/win32 8 Nov 2004 04:56:56 - *** *** 0 --- 1,4 + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + While we are here you could also add -Wl,--enable-auto
Re: [HACKERS] pg buildfarm status update
Andrew Dunstan schrieb: The PG buildfarm has been operational for a little while now, thanks to Joshua and CommandPrompt for the server space. You can see the current status at: http://www.pgbuildfarm.org/cgi-bin/show_status.pl Today for the first time I got a Windows client working, and will be putting the code changes in CVS on pgfoundry soon. Then I will turn to improving the web interface, moving from the rather severely functional setup currently used. Could loris also be used to do the cygwin and MSVC builds? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg buildfarm status update
Andrew Dunstan schrieb: Could loris also be used to do the cygwin and MSVC builds? Cygwin is next on my list. The buildfarm client script does full server builds, so MSVC isn't on the radar right now. FYI the steps in the process are (more or less): configure make make check make contrib make install initdb startdb make installcheck make contrib install make contrib installcheck stopdb I don't intend to use the machine that is loris for long - it's too slow and memory bound. If anyone has a nice fast Windows machine with 1Gb+ of Ram that we could use for a buildfarm client (Windows Native and/or Cygwin) that would be awesome. Sorry, no. Is there no ISP around, which wants to save some money? :) Also, if anyone managed to port ccache to Windows that would be huge too. Using it on Unix has proved to be a major gain. ccache is available via cygwin at least. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] rmtree() failure on Windows
Andrew Dunstan schrieb: problem area found. see below. Reini Urban wrote: Andrew Dunstan schrieb: Here is some more info. Below is a trace from dropdb. There is a loop around the rmdir() calls which I have set to time out at 600 seconds. The call eventually succeeds after around 300 seconds (I've seen this several times). It looks like we are the victim of some caching - the directory still thinks it has some of the files it has told us we have deleted successfully. 300 secs (!) fs timeout is really broken. Looks more like a locking or network timeout issue. What error codes does unlink(3) return? success. Oops! 5min timeout for success is certainly problematic. Why don't you use DeletFileA() instead of unlink()? Or even better, why don't you use this delete on close snippet instead: [snip] Before I tried anything like that I tried one more thing. I disabled the background writer and the problem stopped. So now we know the culprit. Good! Relieve. It should only happen a ERROR_SHARING_VIOLATION on NT systems with such a long timeout. This is then a concurrency problem. win95 will not return ERROR_SHARING_VIOLATION, only ERROR_ACCESS_DENIED We don't support W95/W98/WME at all. The tests were done on XP-Pro. Ah sorry. I forgot. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] src/timezone/pgtz __imp__my_exec_path
beta4 - cygwin: postgres.exe fails to build, because __imp__my_exec_path from src/timezone/pgtz.o cannot be resolved. previously it was not imported. dlltool --dllname postgres.exe --output-exp postgres.exp --def postgres.def gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -L../../src/port -L/usr/local/lib -o postgres.exe -Wl,--base-file,postgres.base postgres.exp access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o -lpgport_srv -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lresolv ../../src/timezone/SUBSYS.o(.text+0x2192):pgtz.c: undefined reference to `__imp__my_exec_path' nm postgresql-8.0.0beta4/src/timezone/pgtz.o |grep my_exec U __imp__my_exec_path but: nm postgresql-8.0.0beta3/src/timezone/pgtz.o |grep my_exec U _my_exec_path The makefile didn't change. The src, cmdline and def file is also the same. It might related to some change in the header files with the pgport_srv seperation. Can somebody give me a hint? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] src/timezone/pgtz __imp__my_exec_path
Magnus Hagander schrieb: beta4 - cygwin: postgres.exe fails to build, because __imp__my_exec_path from src/timezone/pgtz.o cannot be resolved. previously it was not imported. This could be related to the patch that went in last weekend to fix compiles on Win32. DLLIMPORT was added to the header. If the Makefile did not change, then that is your problem - that patch changed botht he makefile and the header. See http://archives.postgresql.org/pgsql-committers/2004-10/msg00321.php Does CYGWIN perhaps need the same Makefile patch? You only patched your Makefile.win32, not Makefile.cygwin. That's it. It builds fine now. Please add also ifneq (,$(findstring timezone,$(subdir))) override CPPFLAGS+= -DBUILDING_DLL endif to the Makefile.cygwin. Without it doesn't break just contrib/tsearch, it even breaks cygwin postmaster. Maybe all win32.mak and bcc32.mak must also be checked. Does anybody do the msvc/borland suites? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] rmtree() failure on Windows
Andrew Dunstan schrieb:
Here is some more info. Below is a trace from dropdb. There is a loop
around the rmdir() calls which I have set to time out at 600 seconds.
The call eventually succeeds after around 300 seconds (I've seen this
several times). It looks like we are the victim of some caching - the
directory still thinks it has some of the files it has told us we have
deleted successfully.
300 secs (!) fs timeout is really broken.
Looks more like a locking or network timeout issue.
What error codes does unlink(3) return?
Why don't you use DeletFileA() instead of unlink()?
Or even better, why don't you use this delete on close snippet instead:
HANDLE h;
h = CreateFile (win32_name, 0, FILE_SHARE_READ, sec_none_nih,
OPEN_EXISTING, FILE_FLAG_DELETE_ON_CLOSE, 0);
if (h != INVALID_HANDLE_VALUE)
{
(void) SetFileAttributes (win32_name, (DWORD) win32_name);
BOOL res = CloseHandle (h);
//syscall_printf (%d = CloseHandle (%p), res, h);
if (GetFileAttributes (win32_name) == INVALID_FILE_ATTRIBUTES)
{
//syscall_printf (CreateFile (FILE_FLAG_DELETE_ON_CLOSE)
succeeded);
goto ok;
}
else
{
//syscall_printf (CreateFile (FILE_FLAG_DELETE_ON_CLOSE) failed);
SetFileAttributes (win32_name, (DWORD) win32_name
~(FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_SYSTEM));
}
}
}
/* Try a delete with attributes reset */
if (DeleteFile (win32_name))
{
syscall_printf (DeleteFile after CreateFile/CloseHandle succeeded);
goto ok;
}
It should only happen a ERROR_SHARING_VIOLATION on NT systems with such
a long timeout. This is then a concurrency problem. win95 will not
return ERROR_SHARING_VIOLATION, only ERROR_ACCESS_DENIED
...
2004-10-26 10:31:09 [2496] WARNING: rmtree: rmdir took 274 secs/loops
2004-10-26 10:31:09 [2496] LOG: disconnection: session time: 0:04:34.11
user=pgrunner database=template1 host=127.0.0.1 port=1918
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Proposed Query Planner TODO items
Tatsuo Ishii schrieb: I see nice graphs for each DBT3 query(for example, http://developer.osdl.org/markw/dbt3-pgsql/42/q_time.png). It seems they do not come with normal dbt3-1.4 kit. How did you get them? Maybe you have slightly modified dbt3 kit? This looks like a simple ploticus one-liner. like: pl -png -o vbars.png -prefab vbars data=dbt3.data x=1 y=2 barwidth=line see for example: http://ploticus.sourceforge.net/doc/prefab_vbars.html or http://phpwiki.sourceforge.net/phpwiki/PhpMemoryExhausted/Testresults -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] rmtree() failure on Windows
Tom Lane schrieb: Andrew Dunstan [EMAIL PROTECTED] writes: Shown below is an extract from the traces of make installcheck in contrib. It is decorated with some extra traces I built into src/port/dirmod.c::rmtree(). It shows quite reproducible failure of rmtree(), mostly at the rmdir calls, but even more worryingly there are consistent unlink failures also. I kinda suspect that what you are looking at is a problem with the delayed-unlinking feature that we built to cope with Windows' inability to unlink open files, ie, it's being a little too slow to do the unlinks. Would you refresh my memory about exactly where and when the unlink happens if the initial try fails? You can have a look into the cygwin sources how we do that :) kinda problematic. http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/delqueue.cc?cvsroot=uberbaum http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/syscalls.cc?cvsroot=uberbaum in short: if the return status of DeleteFileA() is ERROR_SHARING_VIOLATION, defer deletion until the end of the process. but win95 reports ERROR_ACCESS_DENIED and not ERROR_SHARING_VIOLATION as NT does. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Leeuw van der, Tim schrieb: There are certainly cygwin-users trying out PostgreSQL on cygwin on WinXX. If the newest cygwin-version will suddenly stop working under WinXX, they will not be happy. That's why we use cygwin symlinks, not junctions. I've given consideration to the argument that you can no longer take data-directories from the cygwin-version to the native-version... And I think that there's not a *huge* loss there. For me, as an observer and occiasional user/developer, I think the loss of not running on cygwin+winXX is larger. After all, the data can still be dumped / reloaded. And what gives me the certainty that the two versions of PostgreSQL, the cygwin and the native version, are not already compiled in such way that they're not binary compatible? (remember, I'm an outsider on this, with no knowledge of the binary formats, and I'm trying to remain in that perspective for this discussion) See below. Conflicting --enable-integer-datetimes and --enable-multibyte would be an issue. I don't know if and how our converters handle multibyte/non-multibyte, when the backend changes. I don't know what the failure will be when you now try to move a data-directory from the cygwin version to the native version, when cygwin uses a .lnk hack and native uses a junction. Did anyone try? What do the results look like? Is there an acceptable way to stop ppl from trying / give sensible errors without introducing too much crap in the code and without harming ppls data? That's a non-critical issue. You can always replace the cygwin .lnk dir with an actual junction on cygwin also. You'd need to be superuser and use ln -d or get junction from sysinternals.com. But than you must have NTFS4 (same drive) or NTFS5 (other local drive). You can also replace the junction with a cygwin .lnk if you switch to FAT, but then you MUST use the cygwin binaries on the data. Or don't use tablespace at all. It's a pretty esoteric feature at all. But it will get problematic on big/little endian machine changes, and different integer sizes. Don't know if the data is converted on the fly then. I only know of AutoCAD's DWG: they designed its data format and accessors to be machine and CPU independent. And you usually don't copy machine dependent /usr/share/postgresql trees to other machines. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane Sent: Tuesday, October 12, 2004 1:02 AM To: Bruce Momjian Cc: Reini Urban; PostgreSQL Developers; [EMAIL PROTECTED] Subject: Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore Bruce Momjian [EMAIL PROTECTED] writes: OK, I have applied the following patch that uses Cygwin native symlink() instead of the Win32 junctions. The reason for this is that Cygwin symlinks work on Win95/98/ME where junction points do not and we have no way to know what system will be running the Cygwin binaries so the safest bet is to use the Cygwin versions. On Win32 native we only run on systems that support junctions. I think this is probably a net loss, because what it will mean is that you cannot take a data directory built under a Cygwin postmaster and use it under a native postmaster, nor vice versa. Given the number of other ways in which we do not support pre-NT4 Windows systems, what is the benefit of allowing this one? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plans for bitmap indexes?
Josh Berkus schrieb: The most nearly comparable thing is be the notion of partial indexes, where, supposing you had 60 region codes (e.g. - 50 US states, 10 Canadian provinces), you might set up indices thus: I'm afraid that you're mistaken about the functionality of bitmap indexes. The purpose of a bitmap index is not to partition an index, but to allow multiple indexes to be used in the same operation. uh. sorry! In my first harsh replay I didn't know that. I thought you wanted a new index type for binary images in BLOBS. (just some hash, maybe optimized for image similarity) For example, imagine you have a table on a dating website with 18 columns representing 18 different characteristics for matching. Imagine that you index each of those columns seperately. If you do: SELECT * FROM people WHERE orientation = 'gay' AND gender = 'male' AND city = 'San Francisco'; ... then the planner can use an index on orientation OR on gender OR on city, but not all three. Multicolumn indexes are no solution for this use case because you'd have to create a multicolumn index for each possible combo of two or three columns ( 18! ). The Bitmap index allows the query executor to use several indexes on the same operation, comparing them and selecting rows where they overlap like a Venn diagram. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] more dirmod CYGWIN
Bruce Momjian schrieb: Great, just glad we could get it all working. ... Just that regression suite stopped working a while ago :( That's by far more serious than the tiny build patches. http://archives.postgresql.org/pgsql-hackers/2004-09/msg00252.php http://archives.postgresql.org/pgsql-hackers/2004-10/msg00193.php (contains a bad analysis) http://archives.postgresql.org/pgsql-hackers/2004-10/msg00236.php (contains a better description) http://archives.postgresql.org/pgsql-hackers/2004-09/msg00259.php (fails also, but is not related) http://archives.postgresql.org/pgsql-hackers/2004-10/msg00411.php Not related to any patches I posted. Probably related to the fixes you made to make plperl work? Between 4.Sep and 10.Sep. Around that time. 10.Sep was my first hang, but that was the day when I did the cvs up against my 4.Sep release for cygwin. Looks like a strange memory problem to me. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] more dirmod CYGWIN
Bruce Momjian schrieb: I have added the attached patch to allow Cygwin /contrib compiles. I am a little confused why Cygwin requires -lpgport and no other platform does, but it is in the Cygwin-specific section so we can always improve it later if we find the cause. thanks. duplicate does not harm. I tell you when I'll find the real culprit. I thought I knew it last month, but the LDFLAGS / LIBS issue (adding all libs to LDFLAGS) is already fixed now. Index: src/Makefile.shlib === RCS file: /cvsroot/pgsql/src/Makefile.shlib,v retrieving revision 1.83 diff -c -c -r1.83 Makefile.shlib *** src/Makefile.shlib 13 Oct 2004 09:51:47 - 1.83 --- src/Makefile.shlib 13 Oct 2004 10:17:36 - *** *** 216,221 --- 216,223 ifeq ($(PORTNAME), cygwin) shlib = $(NAME)$(DLSUFFIX) + # needed for /contrib modules, not sure why + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian schrieb: Greg Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I have applied the following patch that uses Cygwin native symlink() instead of the Win32 junctions. The reason for this is that Cygwin symlinks work on Win95/98/ME where junction points do not Is this really a Win95/98/ME vs NT distinction or a FAT32 vs NTFS distinction? In which case does an NT machine that happens to be using a FAT32 file system have the same problem? I believe it is OS, not file system. Both: On Win95 family systems you cannot do junctions at all. (must use cygwin instead) Up to NT4 and NTFS4 you can junction across the same harddrive. With FAT, FAT32, VFAT not. (convert) (directory mount points) Since W2k and NTFS5 you can junction across all local volumes. With W2k and NTFS4 or FAT32 not. (convert) (volume mount points. implemented by NTFS5 reparse points) This also works with the new EFS (encrypted filesystem). Don't know how the new WinFS will handle that, but it should not break it. I'm not sure about network drives though. Reparse points don't seem to support network drives. (for now). They do work with simple cygwin symlinks. But Samba and novell shares will need some security tweaks. Esp. when run as service. Is there a reason to make this a compile-time decision? Can't it just try to make a junction and if it fails then use the Cygwin symlink? Yes, if we feel like probing for the Windows OS during runtime. I don't think it is worth it. Agreed. Speed is not a matter for cygwin. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CVS fixed ...
Tom Lane schrieb: liCVS ul lia href=/cvsweb.cgi/pgsql-serverPostgreSQL Server CVS web interface./a lia href=/cvsweb.cgi/interfacesPostgreSQL Interfaces CVS web interface./a lia href=/docs/postgres/cvs.htmlCVS repository retrieval/a /ul The first of these needs to be repointed to .../pgsql, and the second is (I think) entirely dead. When you fixed pgsql-server to pgsql, cannot you leave the old pgsql-server as alias to pgsql? I believe a lot of people checked out with this Repository name. This will not break everything. The docs should be fixed nevertheless. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [CYGWIN] [HACKERS] Need for DLLINIT in Makefile.shlib
Jason Tishler schrieb: On Tue, Oct 12, 2004 at 01:37:48AM +0200, Reini Urban wrote: Bruce Momjian schrieb: I am curious why Cygwin needs DLLINIT in Makefile.shlib, and Win32 doesn't: [snip] The only difference I see is that Cygwin uses $(DLLINIT) while Win32 does not. Is that correct? Why? Both set DLLINIT in their makefiles: DLLINIT = $(top_builddir)/src/utils/dllinit.o Could they be merged into a single snipped of code? Good point! Out of my head: I don't think that we (cygwin) don't need that anymore. With newer binutils it should get autogenerated. But I'll have to test before you can remove that dir. I concur with Reini. The DLLINIT stuff is a vestige from b20.1. FWIW, I attempted to remove it 3 - 4 years ago, but was unsuccessful... I build successfully without this DLLINIT yestreday, and ran then into the one remaining regression error, which I reported before (during inserting some polygons in the parallel suite). But this is for sure not related, so you can safely clean that mess up, (remove that dir) and merge the win32 and cygwin makefile recipe. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] OT moving from MS SQL to PostgreSQL
Greg Stark schrieb: Christopher Browne [EMAIL PROTECTED] writes: - The alternative _I_ would most like would be to deploy web apps in Lisp, but I never have the round tuits to get into that very far... If you find any tuits sometime you might want to check out Per Bothner's Kawa. It's a scheme implementation that compiles to java bytecode. http://www.gnu.org/software/kawa/ Web pages seem to be one of the applications it's being used for. And I must say, every time I work with html I do find myself wishing I working in a language with real macros... But scheme is just scheme. Most people tend to prefer the real thing (Common Lisp) after some time. Esp. when there arose so many new webapps for common lisp lately. See http://www.cliki.net/Web That's a bit more then any scheme can offer, and it's based on an industry standard, in contrary to the existing 100 scheme implementations, which all do it differently on the corner edges. (culprit: tiny standard) Personally I still prefer PHP, because it's a nice package (in contrary to perl) and I can hire more and cheaper dildo's to maintain it then. Manager's prefer that. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Need for DLLINIT in Makefile.shlib
Bruce Momjian schrieb: I am curious why Cygwin needs DLLINIT in Makefile.shlib, and Win32 doesn't: # Cygwin case $(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT) $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS) $(DLLWRAP) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def $(OBJS) $(DLLINIT) $(SHLIB_LINK) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def --output-lib lib$(NAME).a $(DLLINIT): $(DLLINIT:%.o=%.c) $(MAKE) -C $(@D) $(@F) endif # PORTNAME == cygwin else # PORTNAME == win32 # win32 case $(shlib) lib$(NAME).a: $(OBJS) $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS) $(DLLWRAP) -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 endif # PORTNAME == win32 The only difference I see is that Cygwin uses $(DLLINIT) while Win32 does not. Is that correct? Why? Both set DLLINIT in their makefiles: DLLINIT = $(top_builddir)/src/utils/dllinit.o Could they be merged into a single snipped of code? Good point! Out of my head: I don't think that we (cygwin) don't need that anymore. With newer binutils it should get autogenerated. But I'll have to test before you can remove that dir. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian schrieb: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I have applied the following patch that uses Cygwin native symlink() instead of the Win32 junctions. The reason for this is that Cygwin symlinks work on Win95/98/ME where junction points do not and we have no way to know what system will be running the Cygwin binaries so the safest bet is to use the Cygwin versions. On Win32 native we only run on systems that support junctions. I think this is probably a net loss, because what it will mean is that you cannot take a data directory built under a Cygwin postmaster and use it under a native postmaster, nor vice versa. Given the number of other ways in which we do not support pre-NT4 Windows systems, what is the benefit of allowing this one? I assume Cygwin supports pre-NT4, and always has, and I see no reason to change that. Moving a data directory from Cygwin to native Win32 seems like a pretty rare usage to diable pre-NT4 on a platform the previously supported it. ok, thanks. I'll communicate that. It's a new feature, so people will not know what's going on, but they already asked about tablespace. And maybe someone wants to test that on his WinME laptop. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] more dirmod CYGWIN
Tom Lane schrieb: Bruce Momjian [EMAIL PROTECTED] writes: Reini Urban wrote: Now that postgres 8.0 is win32 native is it still necessary support the cygwin ? FYI: If you drop it I will still provide cygwin packages. I just need it for testing and writing applications targetted to unix. With win32 this is not possible. I see no reason _not_ to support Cygwin. Seems like a fine port to me. Cygwin is surely a lot less invasive than the native Windows port ;-) What you have to understand though is that it's now a bit marginalized. The bulk of the Windows usage is going to shift to the native port, so Cygwin support is going to be on the same level as AIX, or HPUX (my personal favorite), or several other platforms I could mention. That is, you gotta keep after the porting issues because not very many other people on pghackers will do it for you. Send in the patches and we'll use 'em, but don't expect that it will happen without your attention. I think the main issue right at the moment is that we probably have not sorted out where WIN32 means any Windows port versus native port only versus Cygwin only. You're on the spot to keep us honest here. Thanks for clarification. Our cygwin community will appreciate it. Esp. because we try to add all the mapping libs and software, which depends on postgresql: mapserver, gdal, postgis, ... And for most of them their only windows ports are cygwin based. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] more dirmod CYGWIN (was: APR 1.0 released)
Gaetano Mendola schrieb: Bruce Momjian wrote: I just made some major Win32 modifications in the past few days. Would you try Cygwin compile and see if the following warnings are removed and the rest of the system builds OK? Now that postgres 8.0 is win32 native is it still necessary support the cygwin ? FYI: If you drop it I will still provide cygwin packages. I just need it for testing and writing applications targetted to unix. With win32 this is not possible. How do want to support postgis or other extensions on win32? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Reini Urban schrieb: Tom Lane schrieb: Bruce Momjian [EMAIL PROTECTED] writes: I am confused. CVS has in port.h: so you should already be calling the junction code on Cygwin. true. didn't thought of that. very strange. Yeah, I'm sure he is, but it looks from the regression results like it doesn't quite work on Cygwin. Is that fixable? I'll step that in the debugger. not yet done. If so, we'd have a choice of whether to rely on junctions or on Cygwin's own emulation of symlinks. I'd be inclined to think the former is a better idea, if only because it'd give you some chance of migrating a data directory between Cygwin and native ports. Cygwin can do symlinks for directories via the magic .lnk file. But Cygwin can also do junctions via hardlinks in ln.exe. I thought link() calls the junction code. I'll investigate why the libc link() failed, and if ln.exe does some sifferent magic, similar to pgsymlink. For the records: Using cygwin native slow symlinks - see attached patch - works fine. Quite an overhead via the magic .lnk file. tablespace tests pass. Should I investigate what users want? 1. speed: * junctions, can only be manipulated via junction.exe (sysinternals.com e.g.) * only w2k and above, 2. or compatibility: * .lnk, can be manipulated with ln.exe * all windows version. even win95 when we fix our outstanding cygserver issues with cygserver - But another problem arose. Doesn't look like a sideeffect caused by my symlink switch. I switched to latest CVS in between. parallel_schedule always fails after finishing create_misc, independent of the order. If it's the first 2nd, 3rd, ... so it's not create_aggregate or any other test there. This is the tail of postmaster.log: ERROR: aggregate nosuchagg(*) does not exist ERROR: operator does not exist: integer ## ERROR: syntax error at or near ) at character 45 ERROR: syntax error at or near IN at character 43 ERROR: new row for relation check_tbl violates check constraint check_con ERROR: new row for relation check_tbl violates check constraint check_con ERROR: new row for relation check_tbl violates check constraint check_con ERROR: new row for relation check2_tbl violates check constraint sequence_con ERROR: new row for relation check2_tbl violates check constraint sequence_con ERROR: new row for relation check2_tbl violates check constraint sequence_con ERROR: new row for relation check2_tbl violates check constraint sequence_con -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ --- postgresql-8.0.0cvs/src/backend/commands/tablespace.c.orig 2004-08-30 04:54:38.0 +0200 +++ postgresql-8.0.0cvs/src/backend/commands/tablespace.c 2004-10-07 14:24:11.731406400 +0200 @@ -51,6 +51,10 @@ */ #include postgres.h +#ifdef __CYGWIN__ +#undef symlink +#endif + #include unistd.h #include dirent.h #include sys/types.h ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] plans for bitmap indexes?
Yann Michel schrieb: I'd like to know if there are any plans on introducing bitmap indexes into postgresql. I think this could mean a big performance improvement especially for datawarehousing applications. I know that there is an index type hash but I don't know how both types are comparable due to they are both best usable for equality expressions. Sure, and the next will come with musicbrainz. Why not :) If you don't want to code that in the app, the database backend is the solution. The database is the golden hammer. http://c2.com/cgi/wiki?GoldenHammer -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] more dirmod CYGWIN
Bruce Momjian schrieb: Reini Urban wrote: Bruce Momjian schrieb: I have applied all parts of your patch now. Thanks. Core builds and works fine now. (plperl IPC problems aside) But there's are still some more minor SHLIB glitches, which only affects contrib, because -lpgport is missing for various dll's. FYI, I think we fixed plperl for Win32 today. !! good to hear. I will come with my promised basic plperl regressiontests soon. No time at all yet. SHLIB_LINK doesn't contain the libs only the paths, because they are filtered out somewhere. But first I want to find the real cause of the problem. Maybe LIB is just missing a -lpgport. Would you please post the link command and error that is failing below: well, all dll contrib's which use pgport functions miss -lpgport. ltree, spi, tsearch, tsearch2, ... make[1]: Entering directory `/usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree' sed 's,MODULE_PATHNAME,$libdir/ltree,g' ltree.sql.in ltree.sql gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o ltree_io.o ltree_io.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o ltree_op.o ltree_op.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o lquery_op.o lquery_op.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o _ltree_op.o _ltree_op.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o crc32.o crc32.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o ltxtquery_io.o ltxtquery_io.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o ltxtquery_op.o ltxtquery_op.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o ltree_gist.o ltree_gist.c gcc -g -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -DLOWER_NODE -I. -I.. /../src/include -c -o _ltree_gist.o _ltree_gist.c dlltool --export-all --output-def ltree.def ltree_io.o ltree_op.o lquery_op.o _ltree_op.o crc32.o ltxtquery_io.o ltxtquery_op.o ltree_gist.o _ltree_gist.o dllwrap -o ltree.dll --dllname ltree.dll --def ltree.def ltree_io.o ltree_op.o lquery_op.o _ltree_op.o crc32.o ltxtquery_io.o ltxtquery_op.o ltree_gist.o _ltree_gist.o ../../src/utils/dllinit.o -L../../src/port -L/usr/local/lib -L../../src/backend -lpostgres lquery_op.o(.text+0x1a4): In function `checkLevel': /usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree/lquery_op.c:94: undefined reference to `_pg_strncasecmp' ltxtquery_op.o(.text+0x1b6): In function `checkcondition_str': /usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree/ltxtquery_op.c:57: undefined reference to `_pg_strncasecmp' collect2: ld gab 1 als Ende-Status zuruck dllwrap: gcc exited with status 1 make[1]: *** [libltree.a] Fehler 1 make[1]: Leaving directory `/usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree' I still have to live with the attached patch, which will give then: make[1]: Entering directory `/usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree' dlltool --export-all --output-def ltree.def ltree_io.o ltree_op.o lquery_op.o _ltree_op.o crc32.o ltxtquery_io.o ltxtquery_op.o ltree_gist.o _ltree_gist.o dllwrap -o ltree.dll --dllname ltree.dll --def ltree.def ltree_io.o ltree_op.o lquery_op.o _ltree_op.o crc32.o ltxtquery_io.o ltxtquery_op.o ltree_gist.o _ltree_gist.o ../../src/utils/dllinit.o -L../ ../src/port -L/usr/local/lib -L../../src/backend -lpostgres -lpgport dlltool --dllname ltree.dll --def ltree.def --output-lib libltree.a make[1]: Leaving directory `/usr/src/postgresql/postgresql-8.0.0cvs/contrib/ltree' make -C src ok make -C contrib ok make check MAX_CONNECTIONS=5 ... hangs as reported today in parallel schedule of create_misc. INSERT INTO iportaltest (i, d, p) VALUES (2, 89.05, '(4.0,2.0),(3.0,1.0)'::polygon); hangs ... until Cancel request sent FATAL: terminating connection due to administrator command I'll investigate why. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ --- postgresql-8.0.0cvs/src/Makefile.shlib.orig 2004-09-03 01:06:43.0 +0200 +++ postgresql-8.0.0cvs/src/Makefile.shlib 2004-10-04 12:39:15.0 +0200 @@ -216,6 +216,7 @@ ifeq ($(PORTNAME), cygwin) shlib= $(NAME)$(DLSUFFIX) + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) -- Reini Urban ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban said: Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) No, of course not. That would only check the machine where you compile, not where you install/run. Tablespaces are not supported on NT4. They throw an error. So just describe in the docs that only NTFS5 (i.e. W2K and up) supports th new tablespace feature. I could find my cygwin niche then to support it by our native and slow symlink implementation :) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] win32 tablespace handing
Reini Urban schrieb: Cygwin can do symlinks for directories via the magic .lnk file. But Cygwin can also do junctions via hardlinks in ln.exe. I thought link() calls the junction code. I'll investigate why the libc link() failed, and if ln.exe does some sifferent magic, similar to pgsymlink. I thought a little bit over this. hardlinks and junctions don't work across physical disks, only symlinks. The whole deal about tablespace locations is to seperate it onto another disc, similar to the mysql innodb secondary storage. (or better db's) For cygwin it is very easy to support symlinks to other discs. Just use the native cygwin symlink(), not using the pgport/dirmode:pgsymlink() hook. Just some #define rename hackery at the beginning of the file. For mingw and the other native WIN32 platforms, you can only support junctions (limited functionality, but fast) or go through the trouble of some symlink emulation. But different to the current pgsymlink code. The only advantage is that this symlink resolver can be held in memory, just needs some dump/restore functions to a .conf file. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] win32 tablespace handing
Bruce Momjian schrieb: Reini Urban schrieb: Cygwin can do symlinks for directories via the magic .lnk file. But Cygwin can also do junctions via hardlinks in ln.exe. I thought link() calls the junction code. I'll investigate why the libc link() failed, and if ln.exe does some sifferent magic, similar to pgsymlink. I thought a little bit over this. hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. Sorry, obviously I just got old information. So we have to update our old cygwin code for NTFS5. You can use Volume Mount Points with DeviceIoControl now too, since Win2000 NTFS 5. Sorry. I only knew about Directory Junction Points. http://www.codeproject.com/w2k/junctionpoints.asp -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian schrieb: Fabien COELHO wrote: Dear hackers, I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted out. ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is still an open issue in current CVS head... waiting for a proper implementation after the brain-storming on what seemed to be the consensus, that is to output a separate SET DEFAULT TABLESPACE somewhere; before object creations in the dump/restore command flow. I've noticed that the item does not seem to appear in Bruce's list, thus I'm afraid it might be lost for 8.0 where I think it belongs... hence this little reminder. It isn't on the open items list because it isn't a _must_ fix for 8.0, though it is still in my mailbox. As I remember it is to allow objects to be created when the schema doesn't exist, and for creating more portable pg_dump CREATE statements. If someone wants to fix that, they have to get it working and get agreement to put it in during beta. It is on the TODO list (the missing schemas part). But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist == -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Gavin Sherry schrieb: On Mon, 4 Oct 2004, Reini Urban wrote: But the regression test fails: (the only failing test against cvs HEAD) This is not only a pg_dump/pg_restore issue, or? -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; ERROR: could not set permissions on directory /no/such/location: No such file or directory -- No such tablespace CREATE TABLE bar (i int) TABLESPACE nosuchspace; ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; = *** *** 38,45 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace is not empty DROP SCHEMA testschema CASCADE; ! NOTICE: drop cascades to table testschema.foo -- Should succeed DROP TABLESPACE testspace; --- 41,49 ERROR: tablespace nosuchspace does not exist -- Fail, not empty DROP TABLESPACE testspace; ! ERROR: tablespace testspace does not exist DROP SCHEMA testschema CASCADE; ! ERROR: schema testschema does not exist -- Should succeed DROP TABLESPACE testspace; + ERROR: tablespace testspace does not exist I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Gavin Sherry schrieb: On Mon, 4 Oct 2004, Reini Urban wrote: I cannot recreate on Linux. What platform, etc, are you on? hmm, I'll investigate then. postgresql latest CVS with 2 minor shlib building patches left (added -lpgport) cygwin-1.5.11 gcc-3.4.1 Hmm.. sounds like we're trying to support tablespaces on a system which doesn't actually support symlinks (in the way we need them). Can any of the windows guys help? Found the error: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -DBUILDING_DLL -c -o tablespace.o tablespace.c no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK. /usr/src/postgresql/postgresql-8.0.0cvs/src/backend/commands $ gcc -E -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -DBUILDING_DLL -c tablespace.c | grep HAVE_SYMLINK none -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Reini Urban schrieb: Tom Lane schrieb: Gavin Sherry [EMAIL PROTECTED] writes: I though this may have been the problem. configure.in defines HAVE_SYMLINK to 1 if we are win32. It seems that for Reini's case we are setting our template (and PORTNAME) to win32 when I suspect it should be cygwin. Anyone got any ideas? What are the prospects of making the junction code work under cygwin? Somethink like the attached patch is easier. Just replace symlink() for dirs with link() #ifdef __CYGWIN__ just wait a sec until the tests run through... (completely fresh build) Needed some time because contrib/earthdistance was missing, so I removed it from the Makefile. sorry, bad: test tablespace ... FAILED 1 of 96 tests failed. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] cygwin test package available
FYI: Soon an experimantal cygwin package will be available via the cywin setup.exe installer, based on a post-beta3 cvs snapshot from today. i.e. * tablespace issues - junctions - not yet solved. * without the missing earthdistance Just to gather more feedback from the cygwin folks. This time contrib is added to the cygwin package. It was not in 7.4.x. Name: postgresql-8.0.0cvs-1 (experimental) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Tom Lane schrieb: Bruce Momjian [EMAIL PROTECTED] writes: I am confused. CVS has in port.h: so you should already be calling the junction code on Cygwin. true. didn't thought of that. very strange. Yeah, I'm sure he is, but it looks from the regression results like it doesn't quite work on Cygwin. Is that fixable? I'll step that in the debugger. If so, we'd have a choice of whether to rely on junctions or on Cygwin's own emulation of symlinks. I'd be inclined to think the former is a better idea, if only because it'd give you some chance of migrating a data directory between Cygwin and native ports. Cygwin can do symlinks for directories via the magic .lnk file. But Cygwin can also do junctions via hardlinks in ln.exe. I thought link() calls the junction code. I'll investigate why the libc link() failed, and if ln.exe does some sifferent magic, similar to pgsymlink. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] cygwin test package available
Dave Page schrieb: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban Sent: 04 October 2004 22:17 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] cygwin test package available FYI: Soon an experimantal cygwin package will be available via the cywin setup.exe installer, based on a post-beta3 cvs snapshot from today. i.e. * tablespace issues - junctions - not yet solved. * without the missing earthdistance Earthdistance is there, just umm, hidden. Following a discussion on another list earlier today, it should be fixed sometime tomorrow. Yes, I saw it. I was in a hurry because of the tablespace test. And I actually had it in my previous build early this day. But then I accidently deleted my whole 8.x archive when I reproduced my package building step, so it got deleted. Anyway, it will be in the next update of course. As soon as the tablespace symlinks are fixed and possible other reports lead to more fixes. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL Core Committee Welcomes New Member
Marc G. Fournier schrieb: In recognition of his role as lead developer on the internationalization front, as well as his invaluble work in both the build and release processes, Peter Eisentraut has been invited, and has accepted, to join the Core Committee. Glückwunsch! -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. Index: src/port/dirmod.c === RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.23 diff -c -c -r1.23 dirmod.c *** src/port/dirmod.c 9 Sep 2004 00:59:49 - 1.23 --- src/port/dirmod.c 10 Sep 2004 02:44:19 - *** *** 36,45 #undef rename #undef unlink ! #ifdef __WIN32__ #include winioctl.h #else - /* __CYGWIN__ */ #include windows.h #include w32api/winioctl.h #endif --- 36,44 #undef rename #undef unlink ! #ifndef __CYGWIN__ #include winioctl.h #else #include windows.h #include w32api/winioctl.h #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] more dirmod CYGWIN (was: APR 1.0 released)
[BTW: there's no need to cc all, I'm subscribed to most lists] Reini Urban schrieb: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. FYI: latest cvs HEAD, without any patches. make runs now through with the expected implicit declaration warnings, but without any errors. Esp. the CYGWIN-specific SHMLIB linking errors are now gone. good! make[2]: Entering directory `/usr/src/postgresql/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../src/port -I../../src/include -c -o dirmod.o dirmod.c dirmod.c: In Funktion pgunlink: dirmod.c:113: Warnung: implicit declaration of function `unlink' dirmod.c: In Funktion rmt_cleanup: dirmod.c:267: Warnung: implicit declaration of function `pgport_pfree' dirmod.c: In Funktion rmtree: dirmod.c:318: Warnung: implicit declaration of function `pgport_palloc' dirmod.c:318: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung dirmod.c:333: Warnung: implicit declaration of function `pgport_pstrdup' dirmod.c:333: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung make check hangs at: running on port 65432 with pid 2304 == creating database regression == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): int2 int4 int8 float4 name varchar numeric which means rename works ok. probably the false implicit declarations in the memory code break it. I'll come with another patch later. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: Reini Urban wrote: Bruce Momjian schrieb: OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. Ok, I'll do an analysis and patch which will have a chance to be accepted. Keeping pgrename in CYGWIN is probably a good idea. At least for consistent error reporting (which helped me in finding the problem) Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.1. we at CYGWIN had similar problems with windows locks on unlink. if unlink fails with ERROR_SHARING_VIOLATION or ERROR_ACCESS_DENIED, unlinking is deferred, put into a delqueue. we do no busy waiting then. it's done on exit. The most common problem is the delete on close semantics to handle removing a file which may be open. rename only fails on open files. we try first MoveFile, if that fails we try MoveFileEx MOVEFILE_REPLACE_EXISTING, but no loop on rename. http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?cvsroot=src http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/delqueue.cc?cvsroot=src -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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: [HACKERS] APR 1.0 released
Andrew Dunstan schrieb: Bruce Momjian wrote: Andrew Dunstan wrote: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. The use of WIN32 was because it usually does mean MinGW and Cygwin. But it doesn't. On MinGW WIN32 is a builtin compiler-defined value, and on Cygwin it isn't. To see this, do: touch empty.c; cpp -dM empty.c | grep WIN32 WIN32 *is* defined by windows.h, but in most cases we only include it if WIN32 is *already* defined. windows.h is included unconditionally in our win32.h, but again in most cases we only include that if WIN32 is already defined. So in most cases where we use it it isn't for Cygwin. But there are a few system include files on Cygwin that include it, so it's not guaranteed, although I don't think those affect us. We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. Would you look around and see if this can be improved. I can't see any. As I said, I did look at all the include cases. That was based on the assumption that we actually wanted what I thought was the intention, namely that WIN32 was for Windows native only. If that's not the case we would need to review every one of the ~300 cases where WIN32 is used in #ifdef and friends. Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also. But I don't do MINGW countertests. I assume you do :) Just palloc misses some pending fixes for CYGWIN. cvs head didn't has this fixed. I'll come with a new patch to cvs HEAD soon. I'm quite busy with apache and php porting also. And I want to be careful not to break the FRONTEND section. At least beta2 needed this patch: --- postgresql-8.0.0beta2/src/include/utils/palloc.h.orig 2004-08-29 05:13:11.0 +0100 +++ postgresql-8.0.0beta2/src/include/utils/palloc.h 2004-09-03 14:03:50.279562100 +0100 @@ -80,7 +80,7 @@ #define pstrdup(str) MemoryContextStrdup(CurrentMemoryContext, (str)) -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) extern void *pgport_palloc(Size sz); extern char *pgport_pstrdup(const char *str); extern void pgport_pfree(void *pointer); -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] more dirmod CYGWIN
Reini Urban schrieb: [BTW: there's no need to cc all, I'm subscribed to most lists] Reini Urban schrieb: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. FYI: latest cvs HEAD, without any patches. make runs now through with the expected implicit declaration warnings, but without any errors. Esp. the CYGWIN-specific SHMLIB linking errors are now gone. good! make[2]: Entering directory `/usr/src/postgresql/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../src/port -I../../src/include -c -o dirmod.o dirmod.c dirmod.c: In Funktion pgunlink: dirmod.c:113: Warnung: implicit declaration of function `unlink' dirmod.c: In Funktion rmt_cleanup: dirmod.c:267: Warnung: implicit declaration of function `pgport_pfree' dirmod.c: In Funktion rmtree: dirmod.c:318: Warnung: implicit declaration of function `pgport_palloc' dirmod.c:318: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung dirmod.c:333: Warnung: implicit declaration of function `pgport_pstrdup' dirmod.c:333: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung make check hangs at: running on port 65432 with pid 2304 == creating database regression == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): int2 int4 int8 float4 name varchar numeric which means rename works ok. probably the false implicit declarations in the memory code break it. I'll come with another patch later. parallel tests hang on cygwin. this is expected. attached is the postmaster stackdump on the parallel test (if you care), and the IPC's during the parallel test (not quite busy...): $ ipcs Message Queues: T ID KEYMODE OWNERGROUP Shared Memory: T ID KEYMODE OWNERGROUP m 1966080 65432001 --rw--- rurban root Semaphores: T ID KEYMODE OWNERGROUP s 1966080 65432001 --rw--- rurban root s 1966081 65432002 --rw--- rurban root s 1966082 65432003 --rw--- rurban root s 1966083 65432004 --rw--- rurban root s 1966084 65432005 --rw--- rurban root s 1966085 65432006 --rw--- rurban root s 1966086 65432007 --rw--- rurban root with the serial schedule all tests but the last pass. test tablespace ... FAILED This is the tail of the postmaster log for this failing test. ERROR: cannot alter table fullname because column people.fn uses its rowtype ERROR: could not create symbolic link /usr/src/postgresql/pgsql/src/test/regress/./tmp_check/data/pg_tblspc/155118: No error ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: could not set permissions on directory /no/such/location: No such file or directory ERROR: tablespace nosuchspace does not exist ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: tablespace testspace does not exist LOG: received smart shutdown request LOG: shutting down LOG: database system is shut down attached is the regression.diffs, and also the overall patch against current CVS HEAD I used for this run. (the move-#undef patch is probably already applied regarding bruce) this should be applied. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ *** ./expected/tablespace.out Fri Sep 10 13:42:08 2004 --- ./results/tablespace.outFri Sep 10 13:53:22 2004 *** *** 1,34 -- create a tablespace we can use CREATE
Re: [HACKERS] more dirmod CYGWIN
Bruce Momjian schrieb: I have applied all parts of your patch now. Thanks. Core builds and works fine now. (plperl IPC problems aside) But there's are still some more minor SHLIB glitches, which only affects contrib, because -lpgport is missing for various dll's. SHLIB_LINK doesn't contain the libs only the paths, because they are filtered out somewhere. But first I want to find the real cause of the problem. Maybe LIB is just missing a -lpgport. $ diff -bu src/Makefile.shlib.orig src/Makefile.shlib --- src/Makefile.shlib.orig 2004-09-03 00:06:43.0 +0100 +++ src/Makefile.shlib 2004-09-10 17:12:18.528655500 +0100 @@ -216,6 +216,7 @@ ifeq ($(PORTNAME), cygwin) shlib= $(NAME)$(DLSUFFIX) + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32) $ diff -bu src/makefiles/pgxs.mk.orig src/makefiles/pgxs.mk --- src/makefiles/pgxs.mk.orig 2004-07-30 13:26:40.0 +0100 +++ src/makefiles/pgxs.mk 2004-09-10 17:09:15.499748300 +0100 @@ -63,7 +63,11 @@ ifdef MODULES override CFLAGS += $(CFLAGS_SL) -SHLIB_LINK += $(BE_DLLLIBS) +ifeq ($(PORTNAME), cygwin) + SHLIB_LINK += $(BE_DLLLIBS) $(LDFLAGS) $(LIBS) -lpgport +else + SHLIB_LINK += $(BE_DLLLIBS) +endif endif ifdef PG_CPPFLAGS -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. Does Cygwin need it? Not really, but it will be lot of new work, which is imho not worth it. In some places the cygwin section calls WinAPI functions. It could be worked around by using the posix/cygwin counterparts. pgsymlink for example. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Tom Lane schrieb: Andrew Dunstan [EMAIL PROTECTED] writes: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. Well, it's easily changed, if all that's needed is a search-and-replace. Suggestions for a better name? MINGW32 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. Ok, I'll do an analysis and patch which will have a chance to be accepted. Keeping pgrename in CYGWIN is probably a good idea. At least for consistent error reporting (which helped me in finding the problem) Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. --- Reini Urban wrote: Bruce Momjian schrieb: I looked at the APR code to get some ideas for the Win32 port. Some of the ideas were good, but in other places like rename they didn't do very well we were better off doing it ourselves and getting it right. I remember looking at their code to fix the rename/unlink while the file is open problem, and they didn't seem to have a fix for that so we developed our own method that works like Unix. sorry, but your rename doesn't work on cygwin. maybe it works with mingw. cygwin has it's own and working way of doing rename's. maybe you should have looked at the cygwin sources instead. (src/winsup/cygwin/syscalls.cc) first doing a WinAPI MoveFileEx and then after a failure trying the cygwin version, which will also try its own MoveFile loop, will not work. they are conflicting. same with unlink, but at least the mingw and cygwin unlink versions don't conflict here. here you don't stack two conflicting loops together. nevertheless cygwin's unlink is much better than pgunlink in case of locking problems. it does its own sort of delayed removal then. IMHO port/dirmod.c is a dirty and half-baked hack, which works for mingw only. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: I looked at the APR code to get some ideas for the Win32 port. Some of the ideas were good, but in other places like rename they didn't do very well we were better off doing it ourselves and getting it right. I remember looking at their code to fix the rename/unlink while the file is open problem, and they didn't seem to have a fix for that so we developed our own method that works like Unix. sorry, but your rename doesn't work on cygwin. maybe it works with mingw. cygwin has it's own and working way of doing rename's. maybe you should have looked at the cygwin sources instead. (src/winsup/cygwin/syscalls.cc) first doing a WinAPI MoveFileEx and then after a failure trying the cygwin version, which will also try its own MoveFile loop, will not work. they are conflicting. same with unlink, but at least the mingw and cygwin unlink versions don't conflict here. here you don't stack two conflicting loops together. nevertheless cygwin's unlink is much better than pgunlink in case of locking problems. it does its own sort of delayed removal then. IMHO port/dirmod.c is a dirty and half-baked hack, which works for mingw only. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Andrew Dunstan schrieb:
Reini Urban said:
Bruce Momjian schrieb:
I looked at the APR code to get some ideas for the Win32 port. Some
of the ideas were good, but in other places like rename they didn't do
very well we were better off doing it ourselves and getting it right.
I remember looking at their code to fix the rename/unlink while the
file is open problem, and they didn't seem to have a fix for that so
we developed our own method that works like Unix.
sorry, but your rename doesn't work on cygwin. maybe it works with
mingw.
cygwin has it's own and working way of doing rename's.
maybe you should have looked at the cygwin sources instead.
(src/winsup/cygwin/syscalls.cc)
first doing a WinAPI MoveFileEx and then after a failure trying the
cygwin version, which will also try its own MoveFile loop, will not
work. they are conflicting.
same with unlink, but at least the mingw and cygwin unlink versions
don't conflict here. here you don't stack two conflicting loops
together. nevertheless cygwin's unlink is much better than pgunlink in
case of locking problems. it does its own sort of delayed removal
then.
IMHO port/dirmod.c is a dirty and half-baked hack, which works for
mingw only.
Are you sure you are reading this code correctly? Your reading would only be
correct if WIN32 is defined on Cygwin - it isn't IIRC (don't have a
convenient way to test ATM). The relevant code is this:
#ifdef WIN32
while (!MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING))
#endif
#ifdef __CYGWIN__
while (rename(from, to) 0)
#endif
If the code doesn't work, please submit empirical proof, rather than make
assertions of half-baked hack. If it's broken we'll fix it. Bruce's point
about the usefulness of APR remains, nonetheless.
I already posted my needed patches to make beta2 work on cygwin.
But on the pqsql-cygwin mailinglist:
http://xarch.tu-graz.ac.at/home/rurban/software/cygwin/postgresql/postgresql-8.0.0beta2-1
Only a plperl problem is pending. BTW: plperl never worked on cygwin before.
FYI: WIN32 is also defined because windows.h is included.
(/usr/incluse/w32api/windef.h)
If you want this or that, do proper nesting, and use #else.
#ifdef __CYGWIN__
while (rename(from, to) 0)
#else
#ifdef WIN32
while (!MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING))
#endif
#endif
You cannot safely assume WIN32 is only defined on mingw, but not on
__CYGWIN__. And you need windows.h because of some winapi calls below.
The same false assumption was also in src/include/utils/palloc.h
But the whole pgrename #ifdef is fragile and a mess.
cygwin rename works good enough, and I just #ifdef'ed it away.
The two #undef need to be inserted before #include unistd.h, otherwise
pgrename will be declared, but rename not.
gcc -E -I../include dirmod-orig.c:
int
pgrename(const char *from, const char *to)
{
int loops = 0;
while (!MoveFileExA(from, to, 1))
while (rename(from, to) 0)
{
if (GetLastError() != 5L)
if ((*__errno()) != 13)
return -1;
pg_usleep(10);
if (loops == 30)
errstart(0, dirmod-orig.c, 87,
__func__), elog_finish(15, could not rename \%s\ to \%s\,
continuing to try,
from, to);
loops++;
}
if (loops 30)
errstart(0, dirmod-orig.c, 98, __func__),
elog_finish(15, completed rename of \%s\ to \%s\, from, to);
return 0;
}
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] plperl regression tests
Is it possible to test for plperl and add some plperl tests to the regression suite? I see the pg_regress installs and runs with_perl=no. The problem is that cygwin postgres builds and runs fine, only the perl extensions fails (IPC problem when loading the huge perl dll). So I really would like to add a simple plperl testcase to the standard distro. Just the sample from the plperl.sgml would be fine. Any general objections? I'll come up with a patch if not, which will check if the postmaster has plperl support and use it then. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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
