Thread: APR 1.0 released
Hi all, now that Apache Portable Runtime was release why don't use it on Postgres? Regards Gaetano Mendola
Gaetano Mendola wrote: > Hi all, > now that Apache Portable Runtime was release why don't > use it on Postgres? > Now that we have discovered the formula for green cheese, why don't we remake the moon out of it? cheers andrew
On Sat, 4 Sep 2004, Gaetano Mendola wrote: > Hi all, > now that Apache Portable Runtime was release why don't > use it on Postgres? Short question: why? what does it give us, other then potential reliance on another project to build ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Gaetano Mendola <mendola@bigfoot.com> writes:
> now that Apache Portable Runtime was release why don't
> use it on Postgres?
The sense of the question is backwards. Why *should* we use it?
regards, tom lane
Tom Lane wrote: > Gaetano Mendola <mendola@bigfoot.com> writes: > >>now that Apache Portable Runtime was release why don't >>use it on Postgres? > > > The sense of the question is backwards. Why *should* we use it? In order to avoid all the annoyance that someone else had in write code portable. I mean, how much time ( I'm not a postgres developer, I like to think, for lack of time ) was spent in order to port postgres to win32 ? Don't you think that use of APR could save time ? Andrew: about the green cheese, why not remake the moon with it if this have some benefit ? Marc: you are not obliged to change APR version each eye blink. Don't you think that use a portable library could savetime ? One example for all: actually postgres is multi process, some time I see my server with 3 CPU in holiday and one overloaded to sort thousand rows. Don't you think in some cases spawn a couple of thread could improve it ? Let me dream that you agree on this and may be in years someone start to do it ( I'm using postgres since when "create or replace function" or "table functions" was a blasphemy so I'm sure that will happen). What are you going to do? Reinvent the hell and create a sort of framework to work with thread dealing with Win32 world ? I don't know if APR provide a spin lock mechanism, tell me how many times did you see discussion here on hackers about on how make the spin lock effective? In my experience I'm a C++ developer and each time I have to do something I full rely on STL, BOOST, XALAN, XERCES and may be I'll use the APR now that seem stable enough and I swear each time my colleagues are reinventing the list, queue, thread interactions.... Regards Gaetano Mendola
Gaetano Mendola <mendola@bigfoot.com> writes:
> Don't you think that use of APR could save time ?
No, because we've already *done* the work it would purport to save.
It would cost us work to adapt our code to sit on top of APR, and
it's not clear to me that we'd be getting anything for it.
IIRC, this was proposed before and we looked at APR in some detail,
and came to the conclusion that it wouldn't be worth changing. See
the archives.
> Don't you think in some cases spawn a couple of
> thread could improve it ?
The fact that we were on top of APR would not automagically mean that
we could thread-ize the backend, nor that we would want to.
> I don't know if APR provide a spin lock mechanism,
You don't even know that, but you're confident that we can throw away
our spinlock work and use APR anyway. You're wasting our time. Get
some evidence if you want to propose this.
regards, tom lane
Gaetano Mendola wrote: > Tom Lane wrote: > >> Gaetano Mendola <mendola@bigfoot.com> writes: >> >>> now that Apache Portable Runtime was release why don't >>> use it on Postgres? >> >> >> >> The sense of the question is backwards. Why *should* we use it? > > > In order to avoid all the annoyance that someone else had in > write code portable. I mean, how much time ( I'm not a postgres > developer, I like to think, for lack of time ) was spent in order > to port postgres to win32 ? Don't you think that use of APR could > save time ? > > Andrew: about the green cheese, why not remake the moon with it > if this have some benefit ? > > Go and study the history of how long it took the Apache people to get APR done. Look at the history of the various MPMs. By contrast, we got our Windows port done in rather less than a year, partly by *not* going down ratholes like APR. Now it's true that they had a different (and harder) set of problems to deal with - in particular scaling to huge numbers of very short-lived connections. Even so, it took them a very long time (years and years) to get right, and they still use a different MPM by default on Windows from what they use on Unix - and you have to choose it at configure time. I am not crtiticizing the Apache people - I am just saying there is no evidence that using APR would have any benefit at all for PostgreSQL - and it would be massively invasive and require huge effort to do so. cheers andrew
Christopher Browne wrote: > ... And since APR isn't BSD licensed, that would probably cause a > problem. They are changin license for APR and I'll be not surprised if they adopth the BSD one. Regards Gaetano Mendola
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Lane wrote: | Gaetano Mendola <mendola@bigfoot.com> writes: |>I don't know if APR provide a spin lock mechanism, | | | You don't even know that, but you're confident that we can throw away | our spinlock work and use APR anyway. You're wasting our time. Get | some evidence if you want to propose this. I'm sorry to have wasted your time. With the experience you have I don't think you need my evidences. Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBOlKM7UpzwH2SGd4RAshqAJ9L1MeBsWlU/G2I1DRoA1/GifMj9ACg/RWX IInlsOU+Z78LSyyL3maBC3Q= =BcID -----END PGP SIGNATURE-----
On Sun, 5 Sep 2004, Gaetano Mendola wrote: > Christopher Browne wrote: > > >> ... And since APR isn't BSD licensed, that would probably cause a >> problem. > > They are changin license for APR and I'll be not surprised if they > adopth the BSD one. Since Apache has developed their own license, and I've seen at least one non-Apache project (Spamassassin) switch over to it so far, I would be very surprised is APR switched a non-Apache license ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Gaetano Mendola wrote: [ PGP not available, raw data follows ] > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Lane wrote: > > | Gaetano Mendola <mendola@bigfoot.com> writes: > |>I don't know if APR provide a spin lock mechanism, > | > | > | You don't even know that, but you're confident that we can throw away > | our spinlock work and use APR anyway. You're wasting our time. Get > | some evidence if you want to propose this. > > I'm sorry to have wasted your time. > > With the experience you have I don't think you need my evidences. 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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/
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 WIN32while (!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. cheers andrew
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 WIN32while (!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(100000); 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/
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. cheers andrew
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. --------------------------------------------------------------------------- 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/ > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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/
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. Done, and patch attached and applied. Hopefully at least Cygwin will compile dirmod.c now. (Most of the patch is consistency reorganization.) We still need a review of that file. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/backend/libpq/be-secure.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/libpq/be-secure.c,v retrieving revision 1.48 diff -c -c -r1.48 be-secure.c *** src/backend/libpq/be-secure.c 29 Aug 2004 05:06:43 -0000 1.48 --- src/backend/libpq/be-secure.c 9 Sep 2004 00:49:26 -0000 *************** *** 659,665 **** * think of a reasonable check to apply on Windows. (See also the * data directory permission check in postmaster.c) */ ! #if !defined(__CYGWIN__) && !defined(WIN32) if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) || buf.st_uid != getuid()) ereport(FATAL, --- 659,665 ---- * think of a reasonable check to apply on Windows. (See also the * data directory permission check in postmaster.c) */ ! #if !defined(WIN32) && !defined(__CYGWIN__) if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) || buf.st_uid != getuid()) ereport(FATAL, Index: src/backend/postmaster/postmaster.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.424 diff -c -c -r1.424 postmaster.c *** src/backend/postmaster/postmaster.c 29 Aug 2004 05:06:46 -0000 1.424 --- src/backend/postmaster/postmaster.c 9 Sep 2004 00:49:34 -0000 *************** *** 976,982 **** * be proper support for Unix-y file permissions. Need to think of a * reasonable check to apply on Windows. */ ! #if !defined(__CYGWIN__) && !defined(WIN32) if (stat_buf.st_mode & (S_IRWXG | S_IRWXO)) ereport(FATAL, (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), --- 976,982 ---- * be proper support for Unix-y file permissions. Need to think of a * reasonable check to apply on Windows. */ ! #if !defined(WIN32) && !defined(__CYGWIN__) if (stat_buf.st_mode & (S_IRWXG | S_IRWXO)) ereport(FATAL, (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), Index: src/include/c.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/c.h,v retrieving revision 1.168 diff -c -c -r1.168 c.h *** src/include/c.h 29 Aug 2004 05:06:55 -0000 1.168 --- src/include/c.h 9 Sep 2004 00:49:38 -0000 *************** *** 68,74 **** #include <sys/types.h> #include <errno.h> ! #if defined(__CYGWIN__) || defined(WIN32) #include <fcntl.h> /* ensure O_BINARY is available */ #endif #ifdef HAVE_SUPPORTDEFS_H --- 68,74 ---- #include <sys/types.h> #include <errno.h> ! #if defined(WIN32) || defined(__CYGWIN__) #include <fcntl.h> /* ensure O_BINARY is available */ #endif #ifdef HAVE_SUPPORTDEFS_H *************** *** 680,686 **** * literal control-Z. The other affect is that we see CRLF, but * that is OK because we can already handle those cleanly. */ ! #if defined(__CYGWIN__) || defined(WIN32) #define PG_BINARY O_BINARY #define PG_BINARY_R "rb" #define PG_BINARY_W "wb" --- 680,686 ---- * literal control-Z. The other affect is that we see CRLF, but * that is OK because we can already handle those cleanly. */ ! #if defined(WIN32) || defined(__CYGWIN__) #define PG_BINARY O_BINARY #define PG_BINARY_R "rb" #define PG_BINARY_W "wb" Index: src/include/port.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/port.h,v retrieving revision 1.59 diff -c -c -r1.59 port.h *** src/include/port.h 9 Sep 2004 00:24:10 -0000 1.59 --- src/include/port.h 9 Sep 2004 00:49:38 -0000 *************** *** 181,187 **** #endif /* Global variable holding time zone information. */ ! #if !defined(__CYGWIN__) #define TIMEZONE_GLOBAL timezone #define TZNAME_GLOBAL tzname #else --- 181,187 ---- #endif /* Global variable holding time zone information. */ ! #ifndef __CYGWIN__ #define TIMEZONE_GLOBAL timezone #define TZNAME_GLOBAL tzname #else Index: src/include/port/win32.h =================================================================== RCS file: /cvsroot/pgsql-server/src/include/port/win32.h,v retrieving revision 1.31 diff -c -c -r1.31 win32.h *** src/include/port/win32.h 31 Aug 2004 11:29:56 -0000 1.31 --- src/include/port/win32.h 9 Sep 2004 00:49:40 -0000 *************** *** 19,25 **** #define USES_WINSOCK /* defines for dynamic linking on Win32 platform */ ! #if defined(__CYGWIN__) || defined(__MINGW32__) #if __GNUC__ && ! defined (__declspec) #error You need egcs 1.1 or newer for compiling! --- 19,25 ---- #define USES_WINSOCK /* defines for dynamic linking on Win32 platform */ ! #if defined(__MINGW32__) || defined(__CYGWIN__) #if __GNUC__ && ! defined (__declspec) #error You need egcs 1.1 or newer for compiling! Index: src/interfaces/ecpg/include/sqlca.h =================================================================== RCS file: /cvsroot/pgsql-server/src/interfaces/ecpg/include/sqlca.h,v retrieving revision 1.26 diff -c -c -r1.26 sqlca.h *** src/interfaces/ecpg/include/sqlca.h 4 Aug 2003 00:43:32 -0000 1.26 --- src/interfaces/ecpg/include/sqlca.h 9 Sep 2004 00:49:40 -0000 *************** *** 2,8 **** #define POSTGRES_SQLCA_H #ifndef DLLIMPORT ! #if defined(__CYGWIN__) || defined(WIN32) #define DLLIMPORT __declspec (dllimport) #else #define DLLIMPORT --- 2,8 ---- #define POSTGRES_SQLCA_H #ifndef DLLIMPORT ! #if defined(WIN32) || defined(__CYGWIN__) #define DLLIMPORT __declspec (dllimport) #else #define DLLIMPORT Index: src/port/dirmod.c =================================================================== RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.22 diff -c -c -r1.22 dirmod.c *** src/port/dirmod.c 29 Aug 2004 05:07:02 -0000 1.22 --- src/port/dirmod.c 9 Sep 2004 00:49:42 -0000 *************** *** 66,79 **** { int loops = 0; ! #ifdef WIN32 while (!MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING)) #endif #ifdef __CYGWIN__ while (rename(from, to) < 0) #endif { ! #ifdef WIN32 if (GetLastError() != ERROR_ACCESS_DENIED) #endif #ifdef __CYGWIN__ --- 66,79 ---- { int loops = 0; ! #if defined(WIN32) && !defined(__CYGWIN__) while (!MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING)) #endif #ifdef __CYGWIN__ while (rename(from, to) < 0) #endif { ! #if defined(WIN32) && !defined(__CYGWIN__) if (GetLastError() != ERROR_ACCESS_DENIED) #endif #ifdef __CYGWIN__
Bruce Momjian said: > 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. > > Done, and patch attached and applied. Hopefully at least Cygwin will > compile dirmod.c now. (Most of the patch is consistency > reorganization.) We still need a review of that file. > I don't understand most of this patch. What difference does changing the preprocessor test order make? cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> I don't understand most of this patch. What difference does changing the
> preprocessor test order make?
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that "if a && !b" is clearer than "if !b && a";
the latter requires a bit more thought to parse the extent of the !
operator...
However, per Michael's report there's some oversight in this patch.
I'm not presently ready to update to CVS tip; who can find the problem?
regards, tom lane
Tom Lane wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > > I don't understand most of this patch. What difference does changing the > > preprocessor test order make? > > I think Bruce was mostly trying to make all the similar tests look > alike. Also I agree that "if a && !b" is clearer than "if !b && a"; > the latter requires a bit more thought to parse the extent of the ! > operator... Right, just consistency. > However, per Michael's report there's some oversight in this patch. > I'm not presently ready to update to CVS tip; who can find the problem? I have not seen the report yet. I had no plan to change the behavior except for Cygwin. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: >Tom Lane wrote: > > >>"Andrew Dunstan" <andrew@dunslane.net> writes: >> >> >>>I don't understand most of this patch. What difference does changing the >>>preprocessor test order make? >>> >>> >>I think Bruce was mostly trying to make all the similar tests look >>alike. Also I agree that "if a && !b" is clearer than "if !b && a"; >>the latter requires a bit more thought to parse the extent of the ! >>operator... >> >> > >Right, just consistency. > > Ok. I understand now. 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. cheers andrew
Andrew Dunstan <andrew@dunslane.net> 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?
regards, tom lane
Tom Lane schrieb: > Andrew Dunstan <andrew@dunslane.net> 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/
Andrew Dunstan wrote: > >>I think Bruce was mostly trying to make all the similar tests look > >>alike. Also I agree that "if a && !b" is clearer than "if !b && a"; > >>the latter requires a bit more thought to parse the extent of the ! > >>operator... > >> > >> > > > >Right, just consistency. > > > > > > > Ok. I understand now. > > 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. 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > Well, it's easily changed, if all that's needed is a search-and-replace. > > Suggestions for a better name? > > MINGW32 I think that is a bad idea. That symbol sure suggests, that you are using mingw. Are you expecting someone who creates a VisualStudio project to define MINGW32 ? Andreas
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 -0000 1.23 > --- src/port/dirmod.c 10 Sep 2004 02:44:19 -0000 > *************** > *** 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/
OK, moved and comment documents its location. --------------------------------------------------------------------------- Reini Urban wrote: > 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 -0000 1.23 > > --- src/port/dirmod.c 10 Sep 2004 02:44:19 -0000 > > *************** > > *** 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/ > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/port/dirmod.c =================================================================== RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.24 diff -c -c -r1.24 dirmod.c *** src/port/dirmod.c 10 Sep 2004 02:49:37 -0000 1.24 --- src/port/dirmod.c 10 Sep 2004 09:51:12 -0000 *************** *** 21,26 **** --- 21,32 ---- #include "postgres_fe.h" #endif + /* Don't modify declarations in system headers */ + #if defined(WIN32) || defined(__CYGWIN__) + #undef rename + #undef unlink + #endif + #include <unistd.h> #include <dirent.h> #include <sys/stat.h> *************** *** 33,41 **** #include "miscadmin.h" - #undef rename - #undef unlink - #ifndef __CYGWIN__ #include <winioctl.h> #else --- 39,44 ----
[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/
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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/
> > 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. What I do not understand is, that Windows has rename and _unlink. Are we using those or not? Looping forever is certainly not good, but I thought the current code had a limited loop. I think a limited loop is required, since both rename and _unlink can not cope with a locked file. Andreas
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. cheers andrew
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.000000000 +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/
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 KEY MODE OWNER GROUP Shared Memory: T ID KEY MODE OWNER GROUP m 1966080 65432001 --rw------- rurban root Semaphores: T ID KEY MODE OWNER GROUP 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.out Fri Sep 10 13:53:22 2004 *************** *** 1,34 **** -- create a tablespace we can use CREATE TABLESPACE testspace LOCATION '/usr/src/postgresql/pgsql/src/test/regress/testtablespace'; -- create a schema in the tablespace CREATE SCHEMA testschema TABLESPACE testspace; -- sanity check SELECT nspname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_namespace n where n.nsptablespace = t.oid and n.nspname = 'testschema'; nspname | spcname ! ------------+----------- ! testschema | testspace ! (1 row) -- try a table CREATE TABLE testschema.foo (i int); SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c where c.reltablespace = t.oid AND c.relname = 'foo'; relname | spcname ! ---------+----------- ! foo | testspace ! (1 row) INSERT INTO testschema.foo VALUES(1); INSERT INTO testschema.foo VALUES(2); -- index CREATE INDEX foo_idx on testschema.foo(i); SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c where c.reltablespace = t.oid AND c.relname = 'foo_idx'; relname | spcname ! ---------+----------- ! foo_idx | testspace ! (1 row) -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; --- 1,37 ---- -- create a tablespace we can use CREATE TABLESPACE testspace LOCATION '/usr/src/postgresql/pgsql/src/test/regress/testtablespace'; + ERROR: could not create symbolic link "/usr/src/postgresql/pgsql/src/test/regress/./tmp_check/data/pg_tblspc/155118":No error -- create a schema in the tablespace CREATE SCHEMA testschema TABLESPACE testspace; + ERROR: tablespace "testspace" does not exist -- sanity check SELECT nspname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_namespace n where n.nsptablespace = t.oid and n.nspname = 'testschema'; nspname | spcname ! ---------+--------- ! (0 rows) -- try a table CREATE TABLE testschema.foo (i int); + ERROR: schema "testschema" does not exist SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c where c.reltablespace = t.oid AND c.relname = 'foo'; relname | spcname ! ---------+--------- ! (0 rows) INSERT INTO testschema.foo VALUES(1); + ERROR: schema "testschema" does not exist INSERT INTO testschema.foo VALUES(2); + ERROR: schema "testschema" does not exist -- index CREATE INDEX foo_idx on testschema.foo(i); + ERROR: schema "testschema" does not exist SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c where c.reltablespace = t.oid AND c.relname = 'foo_idx'; relname | spcname ! ---------+--------- ! (0 rows) -- Will fail with bad path CREATE TABLESPACE badspace LOCATION '/no/such/location'; *************** *** 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 ====================================================================== --- ./src/include/utils/palloc.h.orig 2004-08-29 05:13:11.000000000 +0100 +++ ./src/include/utils/palloc.h 2004-09-10 13:33:04.587653100 +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); --- ./src/port/dirmod.c.orig 2004-09-10 10:29:36.500414700 +0100 +++ ./src/port/dirmod.c 2004-09-10 13:33:53.790148300 +0100 @@ -21,6 +21,9 @@ #include "postgres_fe.h" #endif +#undef rename +#undef unlink + #include <unistd.h> #include <dirent.h> #include <sys/stat.h> @@ -33,9 +36,6 @@ #include "miscadmin.h" -#undef rename -#undef unlink - #ifndef __CYGWIN__ #include <winioctl.h> #else
Reini Urban wrote: > Andrew Dunstan schrieb: > >>> 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 :) > > Cygwin is the likely point of failure here, since we know WIN32 is always defined on MinGW. cheers andrew
Zeugswetter Andreas SB SD wrote: > > > > 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. > > What I do not understand is, that Windows has rename and _unlink. > Are we using those or not? > > Looping forever is certainly not good, but I thought the current code > had a limited loop. I think a limited loop is required, since both > rename and _unlink can not cope with a locked file. The current code prints a log message after 30 tries but keeps trying. We don't use the native ones because they don't work on open files properly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Andrew Dunstan <andrew@dunslane.net> writes:
> 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.
I agree that this is a good idea, partly because I do not care for the
assumption that MINGW is the only compilation environment we'll ever
support for the Windows-native port.
I'm not in a position to work out or test the required changes, but I'll
be happy to apply a patch if you do the legwork ...
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>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. >> >> > >I agree that this is a good idea, partly because I do not care for the >assumption that MINGW is the only compilation environment we'll ever >support for the Windows-native port. > >I'm not in a position to work out or test the required changes, but I'll >be happy to apply a patch if you do the legwork ... > > > > Too big a task for my current time budget :-( - currently my work does not involve any PostgreSQL component, and I am flat out delivering what I am paid for. Unless someone else steps up to the plate it will have to go on the TODO list. cheers andrew
pgman wrote: > Andrew Dunstan wrote: > > >>I think Bruce was mostly trying to make all the similar tests look > > >>alike. Also I agree that "if a && !b" is clearer than "if !b && a"; > > >>the latter requires a bit more thought to parse the extent of the ! > > >>operator... > > >> > > >> > > > > > >Right, just consistency. > > > > > > > > > > > > Ok. I understand now. > > > > 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. 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. OK, I am wrong above. Coding assumes WIN32 is only for port named WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin defined it at all. Are we sure it does in a header file? I wonder if we should just call the port mingw and change the proper defines to __MINGW__. We would then create a define called WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Andrew Dunstan wrote: > >I agree that this is a good idea, partly because I do not care for the > >assumption that MINGW is the only compilation environment we'll ever > >support for the Windows-native port. > > > >I'm not in a position to work out or test the required changes, but I'll > >be happy to apply a patch if you do the legwork ... > > > > > > > > > > Too big a task for my current time budget :-( - currently my work does > not involve any PostgreSQL component, and I am flat out delivering what > I am paid for. I will do it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, change made. Thanks. --------------------------------------------------------------------------- > 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.000000000 +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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > OK, I am wrong above. Coding assumes WIN32 is only for port named > WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin > defined it at all. Are we sure it does in a header file? The problem is that some pieces of Cygwin code include windows.h, which it shouldn't do. If you fix those places, then there is no problem. > I wonder if we should just call the port mingw and change the proper > defines to __MINGW__. We would then create a define called > WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. WIN32 is the correct symbol; see above. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > > OK, I am wrong above. Coding assumes WIN32 is only for port named > > WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin > > defined it at all. Are we sure it does in a header file? > > The problem is that some pieces of Cygwin code include windows.h, which > it shouldn't do. If you fix those places, then there is no problem. There are alot of windows.h includes: /include/port/win32.h:7:#include <windows.h>/port/crypt.c:56:#include <windows.h>/port/dirmod.c:45:#include <windows.h>/port/dirmod.c:405:#include<windows.h>/port/open.c:16:#include <windows.h>/port/sprompt.c:35:#include <windows.h>/timezone/zic.c:22:#include<windows.h>/utils/dllinit.c:44:#include <windows.h>/bin/pgevent/pgevent.c:15:#include"windows.h"/bin/psql/input.c:14:#include <windows.h>/bin/psql/mbprint.c:18:#include<windows.h>/bin/psql/startup.c:16:#include <windows.h>/interfaces/libpq/libpqdll.c:3:#include<windows.h>/interfaces/libpq/pthread-win32.c:14:#include "windows.h"/interfaces/libpq/win32.c:30:#include<windows.h>/backend/port/dynloader/win32.c:3:#include <windows.h> and I bet some of the system includes that we use call windows.h themselves. > > I wonder if we should just call the port mingw and change the proper > > defines to __MINGW__. We would then create a define called > > WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. > > WIN32 is the correct symbol; see above. I hope you are right. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. -- Peter Eisentraut http://developer.postgresql.org/~petere/
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? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I have applied all parts of your patch now. --------------------------------------------------------------------------- Reini Urban wrote: > 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 KEY MODE OWNER GROUP > > Shared Memory: > T ID KEY MODE OWNER GROUP > m 1966080 65432001 --rw------- rurban root > > Semaphores: > T ID KEY MODE OWNER GROUP > 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.out Fri Sep 10 13:53:22 2004 > *************** > *** 1,34 **** > -- create a tablespace we can use > CREATE TABLESPACE testspace LOCATION '/usr/src/postgresql/pgsql/src/test/regress/testtablespace'; > -- create a schema in the tablespace > CREATE SCHEMA testschema TABLESPACE testspace; > -- sanity check > SELECT nspname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_namespace n > where n.nsptablespace = t.oid and n.nspname = 'testschema'; > nspname | spcname > ! ------------+----------- > ! testschema | testspace > ! (1 row) > > -- try a table > CREATE TABLE testschema.foo (i int); > SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c > where c.reltablespace = t.oid AND c.relname = 'foo'; > relname | spcname > ! ---------+----------- > ! foo | testspace > ! (1 row) > > INSERT INTO testschema.foo VALUES(1); > INSERT INTO testschema.foo VALUES(2); > -- index > CREATE INDEX foo_idx on testschema.foo(i); > SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c > where c.reltablespace = t.oid AND c.relname = 'foo_idx'; > relname | spcname > ! ---------+----------- > ! foo_idx | testspace > ! (1 row) > > -- Will fail with bad path > CREATE TABLESPACE badspace LOCATION '/no/such/location'; > --- 1,37 ---- > -- create a tablespace we can use > CREATE TABLESPACE testspace LOCATION '/usr/src/postgresql/pgsql/src/test/regress/testtablespace'; > + ERROR: could not create symbolic link "/usr/src/postgresql/pgsql/src/test/regress/./tmp_check/data/pg_tblspc/155118":No error > -- create a schema in the tablespace > CREATE SCHEMA testschema TABLESPACE testspace; > + ERROR: tablespace "testspace" does not exist > -- sanity check > SELECT nspname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_namespace n > where n.nsptablespace = t.oid and n.nspname = 'testschema'; > nspname | spcname > ! ---------+--------- > ! (0 rows) > > -- try a table > CREATE TABLE testschema.foo (i int); > + ERROR: schema "testschema" does not exist > SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c > where c.reltablespace = t.oid AND c.relname = 'foo'; > relname | spcname > ! ---------+--------- > ! (0 rows) > > INSERT INTO testschema.foo VALUES(1); > + ERROR: schema "testschema" does not exist > INSERT INTO testschema.foo VALUES(2); > + ERROR: schema "testschema" does not exist > -- index > CREATE INDEX foo_idx on testschema.foo(i); > + ERROR: schema "testschema" does not exist > SELECT relname, spcname FROM pg_catalog.pg_tablespace t, pg_catalog.pg_class c > where c.reltablespace = t.oid AND c.relname = 'foo_idx'; > relname | spcname > ! ---------+--------- > ! (0 rows) > > -- Will fail with bad path > CREATE TABLESPACE badspace LOCATION '/no/such/location'; > *************** > *** 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 > > ====================================================================== > > --- ./src/include/utils/palloc.h.orig 2004-08-29 05:13:11.000000000 +0100 > +++ ./src/include/utils/palloc.h 2004-09-10 13:33:04.587653100 +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); > --- ./src/port/dirmod.c.orig 2004-09-10 10:29:36.500414700 +0100 > +++ ./src/port/dirmod.c 2004-09-10 13:33:53.790148300 +0100 > @@ -21,6 +21,9 @@ > #include "postgres_fe.h" > #endif > > +#undef rename > +#undef unlink > + > #include <unistd.h> > #include <dirent.h> > #include <sys/stat.h> > @@ -33,9 +36,6 @@ > > #include "miscadmin.h" > > -#undef rename > -#undef unlink > - > #ifndef __CYGWIN__ > #include <winioctl.h> > #else > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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.000000000 +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.000000000 +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/
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/
Reini Urban wrote: > 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. I'm quite certain we can avoid the problem if we are careful. But wouldn't it be better to get rid of the problem instead by using some other marker? cheers andrew
Andrew Dunstan wrote: > > > Reini Urban wrote: > > > 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. > > > I'm quite certain we can avoid the problem if we are careful. But > wouldn't it be better to get rid of the problem instead by using some > other marker? Agreed. We would never be sure we got them all and new ones didn't get added in over time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Well, glad we are on to real Cygwin issues at least. I know I had
probably broken Cygwin with all the Win32 changes. I actually thought
it would be worse. Glad you were able to help us.
On the /contrib issue, I am not sure we even have Mingw compiling contrib.
What error are you seeing? If I try to compile /contrib/dbsize under
Unix I don't see any -lpgport line in the compile:
$ cd /pgtop/contrib/dbsize/
$ gmake
sed 's,MODULE_PATHNAME,$libdir/dbsize,g' dbsize.sql.in >dbsize.sql
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align -fpic -I.
-I../../src/include -I/usr/local/include/readline -I/usr/contrib/include
-c -o dbsize.o dbsize.c
gcc -shared -o dbsize.so dbsize.o
rm dbsize.o
Let me add that I think the whole FRONTEND flags for /port are a hack
and might need to be change before we hit 8.0 final. They are _very_
fragile but I have not thought of a good solution yet. It is actually
on the open items list.
---------------------------------------------------------------------------
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.
>
> 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.000000000 +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.000000000 +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 majordomo@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> On the /contrib issue, I am not sure we even have Mingw compiling contrib.
We don't --- apparently the win32 crowd hadn't bothered to try it until
recently. There are a couple of patches in the queue that claim to make
individual modules work, but I dunno what the overall situation is.
regards, tom lane
Bruce Momjian wrote: > On the /contrib issue, I am not sure we even have Mingw compiling > contrib. What error are you seeing? If I try to compile > /contrib/dbsize under Unix I don't see any -lpgport line in the > compile: It doesn't need any. It's loaded in the backend, which already has libpgport. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Bruce Momjian wrote: > 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. That has nothing to do with my point. > Does Cygwin need it? No, except in well-controlled circumstances. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > 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. > > That has nothing to do with my point. > > > Does Cygwin need it? > > No, except in well-controlled circumstances. OK, so should we remove the redundant windows.h calls and see what happens? They are testing on WIN32 anyway so I don't even see how Cygwin would be hitting them. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut wrote: > Bruce Momjian wrote: > > On the /contrib issue, I am not sure we even have Mingw compiling > > contrib. What error are you seeing? If I try to compile > > /contrib/dbsize under Unix I don't see any -lpgport line in the > > compile: > > It doesn't need any. It's loaded in the backend, which already has > libpgport. Ah, very tricky. Thanks. But waht about command-line tools in /contrib? Maybe they are OK because I didn't see any fixes like that in the new patches we received. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Centuries ago, Nostradamus foresaw when scrappy@postgresql.org ("Marc G. Fournier") would write:
> On Sat, 4 Sep 2004, Gaetano Mendola wrote:
>> Hi all,
>> now that Apache Portable Runtime was release why don't
>> use it on Postgres?
>
> Short question: why? what does it give us, other then potential
> reliance on another project to build ... ?
It would allow reopening all the threads about why PostgreSQL doesn't
use threading...
That being said, there are places where there would be merit to using
threading in PostgreSQL, though NOT where the usual futile discussions
ask for it. Notably, on an SMP system, it would be a neat idea for
complex queries involving joins to split themselves so that different
parts run in separate threads.
The other Way, Way Cool part would be for queries that are scanning
big tables to split the scans into unions of partial scans, so that on
an 8 CPU box you'd take the "Big 4GB Table" and have 8 threads
simultaneously scanning different parts of it. (And making ARC all
the more important :-).)
But that would, however it happened, involve BIG, SCARY changes...
... And since APR isn't BSD licensed, that would probably cause a
problem.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www3.sympatico.ca/cbbrowne/wp.html
Of course, unless one has a theory, one cannot expect much help from a
computer unless _it_ has a theory)... -- Marvin Minsky
>>>>> "CB" == Christopher Browne <cbbrowne@acm.org> writes: CB> futile discussions ask for it. Notably, on an SMP system, it CB> would be a neat idea for complex queries involvingjoins to CB> split themselves so that different parts run in separate CB> threads. You don't really need threads for this. All you need is to have multiple backends and use queues to exchange tuples at specific points. This is much like the Exchange operator in Volcano. CB> The other Way, Way Cool part would be for queries that are CB> scanning big tables to split the scans into unionsof partial CB> scans, so that on an 8 CPU box you'd take the "Big 4GB Table" CB> and have 8 threads simultaneouslyscanning different parts of CB> it. (And making ARC all the more important :-).) Again this can be done without threads .. you just need inter-process communication. (BTW, there is at least one commercial system that follows exactly this model). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
Any chance of having query parallelization added to TODO? I'm guessing it will be a huge job, but it's also one of the places where the 'big 3' have a huge advantage in scalability. On Mon, Sep 13, 2004 at 10:24:05AM -0700, Sailesh Krishnamurthy wrote: > >>>>> "CB" == Christopher Browne <cbbrowne@acm.org> writes: > > CB> futile discussions ask for it. Notably, on an SMP system, it > CB> would be a neat idea for complex queries involving joins to > CB> split themselves so that different parts run in separate > CB> threads. > > You don't really need threads for this. All you need is to have > multiple backends and use queues to exchange tuples at specific > points. This is much like the Exchange operator in Volcano. > > CB> The other Way, Way Cool part would be for queries that are > CB> scanning big tables to split the scans into unions of partial > CB> scans, so that on an 8 CPU box you'd take the "Big 4GB Table" > CB> and have 8 threads simultaneously scanning different parts of > CB> it. (And making ARC all the more important :-).) > > Again this can be done without threads .. you just need inter-process > communication. > > (BTW, there is at least one commercial system that follows exactly > this model). > > -- > Pip-pip > Sailesh > http://www.cs.berkeley.edu/~sailesh > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Added to TODO: * Consider parallel processing a single query This would involve using multiple threads or processes to do optimization, sorting, or execution of single query. The majoradvantage of such a feature would be to allow multiple CPUs to work together to process a single query. --------------------------------------------------------------------------- Jim C. Nasby wrote: > Any chance of having query parallelization added to TODO? I'm guessing > it will be a huge job, but it's also one of the places where the 'big 3' > have a huge advantage in scalability. > > On Mon, Sep 13, 2004 at 10:24:05AM -0700, Sailesh Krishnamurthy wrote: > > >>>>> "CB" == Christopher Browne <cbbrowne@acm.org> writes: > > > > CB> futile discussions ask for it. Notably, on an SMP system, it > > CB> would be a neat idea for complex queries involving joins to > > CB> split themselves so that different parts run in separate > > CB> threads. > > > > You don't really need threads for this. All you need is to have > > multiple backends and use queues to exchange tuples at specific > > points. This is much like the Exchange operator in Volcano. > > > > CB> The other Way, Way Cool part would be for queries that are > > CB> scanning big tables to split the scans into unions of partial > > CB> scans, so that on an 8 CPU box you'd take the "Big 4GB Table" > > CB> and have 8 threads simultaneously scanning different parts of > > CB> it. (And making ARC all the more important :-).) > > > > Again this can be done without threads .. you just need inter-process > > communication. > > > > (BTW, there is at least one commercial system that follows exactly > > this model). > > > > -- > > Pip-pip > > Sailesh > > http://www.cs.berkeley.edu/~sailesh > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > Jim C. Nasby, Database Consultant decibel@decibel.org > Give your computer some brain candy! www.distributed.net Team #1828 > > Windows: "Where do you want to go today?" > Linux: "Where do you want to go tomorrow?" > FreeBSD: "Are you guys coming, or what?" > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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? --------------------------------------------------------------------------- Reini Urban wrote: > [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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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. > 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: --------------------------------------------------------------------------- > > > $ diff -bu src/Makefile.shlib.orig src/Makefile.shlib > --- src/Makefile.shlib.orig 2004-09-03 00:06:43.000000000 +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.000000000 +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 majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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 zur"uck
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.000000000 +0200
+++ postgresql-8.0.0cvs/src/Makefile.shlib 2004-10-04 12:39:15.000000000 +0200
@@ -216,6 +216,7 @@
ifeq ($(PORTNAME), cygwin)
shlib = $(NAME)$(DLSUFFIX)
+ SHLIB_LINK += -lpgport
endif
ifeq ($(PORTNAME), win32)
On Thu, 7 Oct 2004, Bruce Momjian wrote: > > Added to TODO: > > * Consider parallel processing a single query > > This would involve using multiple threads or processes to do optimization, > sorting, or execution of single query. The major advantage of such a > feature would be to allow multiple CPUs to work together to process a > single query. Do we have 'make backend thread safe' listed yet? As I recall it, until that gets done, parallelization of anything was considered to be a relatively onerous task, no? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 7 Oct 2004, Bruce Momjian wrote: > > > > > Added to TODO: > > > > * Consider parallel processing a single query > > > > This would involve using multiple threads or processes to do optimization, > > sorting, or execution of single query. The major advantage of such a > > feature would be to allow multiple CPUs to work together to process a > > single query. > > Do we have 'make backend thread safe' listed yet? As I recall it, until > that gets done, parallelization of anything was considered to be a > relatively onerous task, no? Well, not really. We could perhaps make sorting be thread-safe without doing the entire backend itself. The only trick would be making modules used by sorting thread-safe, not the whole thing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Marc G. Fournier wrote: > Do we have 'make backend thread safe' listed yet? As I recall it, until > that gets done, parallelization of anything was considered to be a > relatively onerous task, no? ISTM there's no reason we couldn't parallelize query execution using the same IPC techniques that we use now. What would be the advantage of using threads instead? -Neil
Neil Conway wrote: > Marc G. Fournier wrote: > > Do we have 'make backend thread safe' listed yet? As I recall it, until > > that gets done, parallelization of anything was considered to be a > > relatively onerous task, no? > > ISTM there's no reason we couldn't parallelize query execution using the > same IPC techniques that we use now. What would be the advantage of > using threads instead? Separate processes. Yes, we could do that too and the item mentions that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
A while back I was looking the backend code in preparation to start
beginning to look at parallelization techniques for PG ;)... My
thought was instead of trying to parallelize each individual plan node
(multi-process sort, etc.) I would look at creating worker
threads/processes for each plan node as a whole. For example, take a
plan that looks like this:
QUERY
PLAN
---------------------------------------------------------------------------------------------------------------------------------------------Subquery
Scanmetarecord_field_entry_view (cost=5.32..4038.80
rows=21 width=112) -> Append (cost=5.32..4038.59 rows=21 width=112) -> Subquery Scan "*SELECT* 1"
(cost=5.32..5.33rows=1 width=74) -> HashAggregate (cost=5.32..5.32 rows=1 width=74)
-> Index Scan using tmr_fe_field on
metarecord_title_field_entry (cost=0.00..5.31 rows=1 width=74) Index Cond: (field =
'added_entry_author'::text) Filter: ((field_class = 'title'::text) AND
(value ~~* '% joe %'::text)) -> Subquery Scan "*SELECT* 2" (cost=4031.02..4031.20
rows=18 width=62) -> HashAggregate (cost=4031.02..4031.02 rows=18 width=62) -> Seq
Scanon metarecord_author_field_entry
(cost=0.00..4030.79 rows=18 width=62) Filter: ((field_class = 'author'::text) AND
(field = 'added_entry_author'::text) AND (value ~~* '% joe %'::text)) -> Subquery Scan "*SELECT* 3"
(cost=2.03..2.04rows=1 width=81) -> HashAggregate (cost=2.03..2.03 rows=1 width=81)
-> Index Scan using smr_fe_field on
metarecord_subject_field_entry (cost=0.00..2.02 rows=1 width=81) Index Cond: (field =
'added_entry_author'::text) Filter: ((field_class = 'subject'::text)
AND (value ~~* '% joe %'::text)) -> Subquery Scan "*SELECT* 4" (cost=0.01..0.02 rows=1 width=112)
-> HashAggregate (cost=0.01..0.01 rows=1 width=112) -> Seq Scan on metarecord_misc_field_entry
(cost=0.00..0.00 rows=1 width=112) Filter: ((field_class = 'misc'::text) AND
(field = 'added_entry_author'::text) AND (value ~~* '% joe %'::text))
The optimizer would look at each node as it walked down the tree and
see that 'Append' node has multiple peer child nodes. It would look
at the cost estimate of the child nodes and if that cost is greater
that the total average cost across all nodes it would spin off a
worker thread/process to handle gathering the sub-resultset.
In any case, I've no time to even *start* looking into something like
that. But even if I did, am I all wet?
--miker
On Fri, 8 Oct 2004 11:56:27 -0400 (EDT), Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
> Neil Conway wrote:
> > Marc G. Fournier wrote:
> > > Do we have 'make backend thread safe' listed yet? As I recall it, until
> > > that gets done, parallelization of anything was considered to be a
> > > relatively onerous task, no?
> >
> > ISTM there's no reason we couldn't parallelize query execution using the
> > same IPC techniques that we use now. What would be the advantage of
> > using threads instead?
>
> Separate processes. Yes, we could do that too and the item mentions that.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
Mariposa was an interesting cost-based distributed query engine based upon PostgreSQL. Perhaps that study may prove valuable insights. http://epoch.cs.berkeley.edu:8000/mariposa/
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 ? Regards Gaetano Mendola
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/
>>>>> "Marc" == Marc G Fournier <scrappy@postgresql.org> writes: Marc> On Thu, 7 Oct 2004, Bruce Momjian wrote: >> Added to TODO: >> >> * Consider parallel processing a singlequery >> >> This would involve using multiple threads or processes to do >> optimization, sorting, or executionof single query. The major >> advantage of such a feature would be to allow multiple CPUs to >> work togetherto process a single query. Marc> Do we have 'make backend thread safe' listed yet? As I Marc> recall it, until that gets done, parallelizationof anything Marc> was considered to be a relatively onerous task, no? You don't really need to parallelize in separate threads .. you can have more than one process working on one query. This is in fact the model that exploits SMPs in at least one commercial RDBMS. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
IMHO the best references to parallelizing query plans are in the Volcano papers. The Exchange operator is a really clean abstraction - the idea is to place the Exchange operator in query plans and that way you don't have to paralellize any other operator. Exchange takes care of managing the IPC queues and also worries about whether or not you have to, say, "rehash the data", or "broadcast the data to all other processes" or "direct the data to a single node" ... I'd suggest reading the following paper: "Encapsulation of parallelism in the Volcano query processing system" By Goetz Graefe in SIGMOD 1990. Link: http://portal.acm.org/citation.cfm?id=98720 The above link also has references to Gamma but I really like the exposition in the Volcano/Exchange work much better. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
Reini Urban wrote: > 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? I see no reason _not_ to support Cygwin. Seems like a fine port to me. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Querying the Internet with PIER" is an interesting recent paper. Authored at Berkeley -- same spawning grounds as PostgreSQL. ;-) Authors: Ryan Huebsch, Joseph M. Hellerstein, Nick Lanham, Boon Thau Loo, Scott Shenker, Ion Stoica > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of > Sailesh Krishnamurthy > Sent: Friday, October 08, 2004 5:00 PM > To: Mike Rylander > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] APR 1.0 released > > > > IMHO the best references to parallelizing query plans are in > the Volcano papers. The Exchange operator is a really clean > abstraction - the idea is to place the Exchange operator in > query plans and that way you don't have to paralellize any > other operator. Exchange takes care of managing the IPC > queues and also worries about whether or not you have to, > say, "rehash the data", or "broadcast the data to all other > processes" or "direct the data to a single node" ... > > I'd suggest reading the following paper: > > "Encapsulation of parallelism in the Volcano query processing system" > > By Goetz Graefe in SIGMOD 1990. > > Link: http://portal.acm.org/citation.cfm?id=98720 > > The above link also has references to Gamma but I really like > the exposition in the Volcano/Exchange work much better. > > -- > Pip-pip > Sailesh > http://www.cs.berkeley.edu/~sailesh > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend >
Bruce Momjian <pgman@candle.pha.pa.us> 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.
regards, tom lane
Tom Lane schrieb: > Bruce Momjian <pgman@candle.pha.pa.us> 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/
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. --------------------------------------------------------------------------- Reini Urban wrote: > 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 zur"uck > 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.000000000 +0200 > +++ postgresql-8.0.0cvs/src/Makefile.shlib 2004-10-04 12:39:15.000000000 +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 majordomo@postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 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 -0000 1.83 --- src/Makefile.shlib 13 Oct 2004 10:17:36 -0000 *************** *** 216,221 **** --- 216,223 ---- ifeq ($(PORTNAME), cygwin) shlib = $(NAME)$(DLSUFFIX) + # needed for /contrib modules, not sure why + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32)
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 -0000 1.83 > --- src/Makefile.shlib 13 Oct 2004 10:17:36 -0000 > *************** > *** 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/