Thread: stat() vs cygwin
It seems my fix for stat() broke cygwin, because it doesn't have
dosmaperr() available. The way I see it there are two ways to fix this:
1) Don't apply the stat fix for cygwin.
2) Make our dosmaperr() function be used on cygwin.
I don't know if the fix is actually needed on cygwin. Can someone with
access to such an environment test it and see?
The easy check, easier than the table, goes something along the line
of:
CREATE TABLE test(t int);
INSERT INTO test(t) SELECT * FROM generate_series(1,100000);
SELECT pg_relation_size('t');
SELECT pg_sleep(5);
SELECT pg_relation_size('t');
Without the patch on win32, the first pg_relation_size comes out as 0,
and the second one correct. With the patch, they come out equal. They
should, of course, always come out equal.
//Magnus
Magnus Hagander <magnus@hagander.net> writes:
> It seems my fix for stat() broke cygwin, because it doesn't have
> dosmaperr() available.
Are you sure you aren't just missing an #include? The other places
where we call _dosmaperr don't seem to be protected by anything more
than #ifdef WIN32.
regards, tom lane
Magnus, was this fixed/resolved?
---------------------------------------------------------------------------
Magnus Hagander wrote:
> It seems my fix for stat() broke cygwin, because it doesn't have
> dosmaperr() available. The way I see it there are two ways to fix this:
>
> 1) Don't apply the stat fix for cygwin.
>
> 2) Make our dosmaperr() function be used on cygwin.
>
>
> I don't know if the fix is actually needed on cygwin. Can someone with
> access to such an environment test it and see?
>
> The easy check, easier than the table, goes something along the line
> of:
> CREATE TABLE test(t int);
> INSERT INTO test(t) SELECT * FROM generate_series(1,100000);
> SELECT pg_relation_size('t');
> SELECT pg_sleep(5);
> SELECT pg_relation_size('t');
>
>
> Without the patch on win32, the first pg_relation_size comes out as 0,
> and the second one correct. With the patch, they come out equal. They
> should, of course, always come out equal.
>
> //Magnus
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Yes.
As in the cygwin build does build. Nobody really has verified if the fix
is needed there. But frankly, if you are likely to care about the
effects of this issue, you won't be running cygwin anyway. It's mostly a
dead platform for postgresql anyway, AFAICS we only keep it building for
legacy compatibility. Once it starts taking lots of resources to keep
building (which it doesn't now), I think we should just drop it instead...
//Magnus
Bruce Momjian wrote:
> Magnus, was this fixed/resolved?
>
> ---------------------------------------------------------------------------
>
> Magnus Hagander wrote:
>> It seems my fix for stat() broke cygwin, because it doesn't have
>> dosmaperr() available. The way I see it there are two ways to fix this:
>>
>> 1) Don't apply the stat fix for cygwin.
>>
>> 2) Make our dosmaperr() function be used on cygwin.
>>
>>
>> I don't know if the fix is actually needed on cygwin. Can someone with
>> access to such an environment test it and see?
>>
>> The easy check, easier than the table, goes something along the line
>> of:
>> CREATE TABLE test(t int);
>> INSERT INTO test(t) SELECT * FROM generate_series(1,100000);
>> SELECT pg_relation_size('t');
>> SELECT pg_sleep(5);
>> SELECT pg_relation_size('t');
>>
>>
>> Without the patch on win32, the first pg_relation_size comes out as 0,
>> and the second one correct. With the patch, they come out equal. They
>> should, of course, always come out equal.
>>
>> //Magnus
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote: > Yes. > > As in the cygwin build does build. Nobody really has verified if the fix > is needed there. But frankly, if you are likely to care about the > effects of this issue, you won't be running cygwin anyway. It's mostly a > dead platform for postgresql anyway, AFAICS we only keep it building for > legacy compatibility. Once it starts taking lots of resources to keep > building (which it doesn't now), I think we should just drop it instead... FWIW, the most recent packages from Cygwin themselves are 8.2.5. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping support would be an
option. I would check this for you, but I am in the middle of moving
and my Windows/Cygwin box is not available right now.
Cheers,
Ken
On Tue, Jun 24, 2008 at 10:32:08AM +0200, Magnus Hagander wrote:
> Yes.
>
> As in the cygwin build does build. Nobody really has verified if the fix
> is needed there. But frankly, if you are likely to care about the
> effects of this issue, you won't be running cygwin anyway. It's mostly a
> dead platform for postgresql anyway, AFAICS we only keep it building for
> legacy compatibility. Once it starts taking lots of resources to keep
> building (which it doesn't now), I think we should just drop it instead...
>
> //Magnus
>
> Bruce Momjian wrote:
> > Magnus, was this fixed/resolved?
> >
> > ---------------------------------------------------------------------------
> >
> > Magnus Hagander wrote:
> >> It seems my fix for stat() broke cygwin, because it doesn't have
> >> dosmaperr() available. The way I see it there are two ways to fix this:
> >>
> >> 1) Don't apply the stat fix for cygwin.
> >>
> >> 2) Make our dosmaperr() function be used on cygwin.
> >>
> >>
> >> I don't know if the fix is actually needed on cygwin. Can someone with
> >> access to such an environment test it and see?
> >>
> >> The easy check, easier than the table, goes something along the line
> >> of:
> >> CREATE TABLE test(t int);
> >> INSERT INTO test(t) SELECT * FROM generate_series(1,100000);
> >> SELECT pg_relation_size('t');
> >> SELECT pg_sleep(5);
> >> SELECT pg_relation_size('t');
> >>
> >>
> >> Without the patch on win32, the first pg_relation_size comes out as 0,
> >> and the second one correct. With the patch, they come out equal. They
> >> should, of course, always come out equal.
> >>
> >> //Magnus
> >>
> >> --
> >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-hackers
> >
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
Kenneth Marshall wrote: > One motivation for keeping it working on Cygwin, is that in some > environments it is not allowed to install native Windows apps but > they allow the use of the Cygwin environment. Of course if it takes > too many resources to support, then dropping support would be an > option. I would check this for you, but I am in the middle of moving > and my Windows/Cygwin box is not available right now. Does anybody seriously have such a broken policy? I know a lot of places who have inverse policy, where they don't allow cygwin, but I've never heard of anybody refusing native programs and only allowing cygwin. Just like I've heard of no linux shops requiring that you run your database under wine... //Magnus
The case I am referring to has a "developer" clause that allows Cygwin applications to be used for development only. I agree that the policy is odd. Ken On Tue, Jun 24, 2008 at 02:35:50PM +0200, Magnus Hagander wrote: > Kenneth Marshall wrote: > > One motivation for keeping it working on Cygwin, is that in some > > environments it is not allowed to install native Windows apps but > > they allow the use of the Cygwin environment. Of course if it takes > > too many resources to support, then dropping support would be an > > option. I would check this for you, but I am in the middle of moving > > and my Windows/Cygwin box is not available right now. > > Does anybody seriously have such a broken policy? I know a lot of places > who have inverse policy, where they don't allow cygwin, but I've never > heard of anybody refusing native programs and only allowing cygwin. Just > like I've heard of no linux shops requiring that you run your database > under wine... > > //Magnus > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Magnus Hagander wrote: > Kenneth Marshall wrote: > >> One motivation for keeping it working on Cygwin, is that in some >> environments it is not allowed to install native Windows apps but >> they allow the use of the Cygwin environment. Of course if it takes >> too many resources to support, then dropping support would be an >> option. I would check this for you, but I am in the middle of moving >> and my Windows/Cygwin box is not available right now. >> > > Does anybody seriously have such a broken policy? I know a lot of places > who have inverse policy, where they don't allow cygwin, but I've never > heard of anybody refusing native programs and only allowing cygwin. Just > like I've heard of no linux shops requiring that you run your database > under wine... > > > This whole argument is pointless, ISTM. We are not in the business of telling people what environment to use Postgres in. Using Cygwin is still the best way I know of to use psql on Windows, and it works just fine as a development environment. By contrast, setting up a development environment for the native build in either supported flavor is distinctly non-trivial. (And yes I know about the problems Cygwin causes if you put it in the System PATH. Don't do that.) More to the point: I thought this had been tested. I will test it today so we can put this whole thread to rest. cheers andrew
Andrew Dunstan wrote: > > > Magnus Hagander wrote: >> Kenneth Marshall wrote: >> >>> One motivation for keeping it working on Cygwin, is that in some >>> environments it is not allowed to install native Windows apps but >>> they allow the use of the Cygwin environment. Of course if it takes >>> too many resources to support, then dropping support would be an >>> option. I would check this for you, but I am in the middle of moving >>> and my Windows/Cygwin box is not available right now. >>> >> >> Does anybody seriously have such a broken policy? I know a lot of places >> who have inverse policy, where they don't allow cygwin, but I've never >> heard of anybody refusing native programs and only allowing cygwin. Just >> like I've heard of no linux shops requiring that you run your database >> under wine... >> >> >> > > This whole argument is pointless, ISTM. We are not in the business of > telling people what environment to use Postgres in. Well, agreed, the argument was that it should be dropped *IF* it turns into a maintenance burden. Which it hasn't yet done. > More to the point: I thought this had been tested. I will test it today > so we can put this whole thread to rest. IIRC it was only tested insofar that it doesn't actually break. Not if it returns proper results. Buf if my memory isn't completely off, there are other such cases as well around the code, where we've done proper fixes for native win32 and left cygwin alone. The argument being that for a developer system, it doesn't really matter if things aren't entirely reliable, and that nobody should be using cygwin for a production server. (I have nothing against using it for a dev box, though I wouldn't do it myself) //Magnus
Magnus Hagander wrote: >> More to the point: I thought this had been tested. I will test it today >> so we can put this whole thread to rest. >> > > IIRC it was only tested insofar that it doesn't actually break. Not if > it returns proper results. > I have tested it using the suggested script (corrected) and it passes (both sizes the same) consistently, as I expected. > Buf if my memory isn't completely off, there are other such cases as > well around the code, where we've done proper fixes for native win32 and > left cygwin alone. The argument being that for a developer system, it > doesn't really matter if things aren't entirely reliable, and that > nobody should be using cygwin for a production server. (I have nothing > against using it for a dev box, though I wouldn't do it myself) > > > I don't recall any. But I could be wrong. cheers andrew
Dave Page schrieb:
> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> Yes.
>>
>> As in the cygwin build does build. Nobody really has verified if the fix
>> is needed there. But frankly, if you are likely to care about the
>> effects of this issue, you won't be running cygwin anyway. It's mostly a
>> dead platform for postgresql anyway, AFAICS we only keep it building for
>> legacy compatibility. Once it starts taking lots of resources to keep
>> building (which it doesn't now), I think we should just drop it instead...
"Dead" is interesting. We see a lot of cygwin users having postgresql
installed.
> FWIW, the most recent packages from Cygwin themselves are 8.2.5.
Update: 8.2.9 is latest.
8.3.x not because the new SSPI doesn't work yet.
currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java
--with-ossp-uuid --with-ldap
(but ldap works okay with 8.2.9)
currently testing is: --enable-nls --with-CXX --with-openssl --with-perl
--with-python --with-libxml --with-libxslt
current cygwin patch in testing is attached.
--
Reini Urban
postgresql cygwin maintainer
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/backend/libpq/auth.csrc/postgresql-8.3.3/src/backend/libpq/auth.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/auth.c 2008-02-08 17:58:46.000000000 +0000
+++ src/postgresql-8.3.3/src/backend/libpq/auth.c 2008-06-28 08:27:03.531250000 +0000
@@ -32,6 +32,9 @@
#include "libpq/pqformat.h"
#include "storage/ipc.h"
+#ifdef __CYGWIN__
+#define WIN32
+#endif
static void sendAuthRequest(Port *port, AuthRequest areq);
static void auth_failed(Port *port, int status);
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.csrc/postgresql-8.3.3/src/backend/libpq/be-secure.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-01-01 19:45:49.000000000 +0000
+++ src/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-06-28 08:27:03.546875000 +0000
@@ -280,9 +280,26 @@
case SSL_ERROR_WANT_WRITE:
#ifdef WIN32
pgwin32_waitforsinglesocket(SSL_get_fd(port->ssl),
- (err == SSL_ERROR_WANT_READ) ?
- FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
- INFINITE);
+ (err == SSL_ERROR_WANT_READ) ?
+ FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
+ INFINITE);
+#elif defined(__CYGWIN__)
+ /* be nicer on cygwin also */
+ {
+ fd_set rset;
+ int sel_res;
+ struct timeval tv;
+ FD_ZERO(&rset);
+ FD_SET(SSL_get_fd(port->ssl), &rset);
+ tv.tv_sec = 0;
+ tv.tv_usec = 500000;
+ sel_res = select(FD_SETSIZE,
+ (err == SSL_ERROR_WANT_READ) ? &rset : NULL,
+ (err == SSL_ERROR_WANT_READ) ? NULL : &rset,
+ NULL, &tv);
+ if (sel_res >= 0 || errno != EINTR)
+ break;
+ }
#endif
goto rloop;
case SSL_ERROR_SYSCALL:
@@ -374,9 +391,25 @@
case SSL_ERROR_WANT_WRITE:
#ifdef WIN32
pgwin32_waitforsinglesocket(SSL_get_fd(port->ssl),
- (err == SSL_ERROR_WANT_READ) ?
- FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
- INFINITE);
+ (err == SSL_ERROR_WANT_READ) ?
+ FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
+ INFINITE);
+#elif defined(__CYGWIN__)
+ {
+ fd_set rset;
+ int sel_res;
+ struct timeval tv;
+ FD_ZERO(&rset);
+ FD_SET(SSL_get_fd(port->ssl), &rset);
+ tv.tv_sec = 0;
+ tv.tv_usec = 500000;
+ sel_res = select(FD_SETSIZE,
+ (err == SSL_ERROR_WANT_READ) ? &rset : NULL,
+ (err == SSL_ERROR_WANT_READ) ? NULL : &rset,
+ NULL, &tv);
+ if (sel_res >= 0 || errno != EINTR)
+ break;
+ }
#endif
goto wloop;
case SSL_ERROR_SYSCALL:
@@ -560,8 +593,8 @@
dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
if (dh == NULL)
ereport(DEBUG2,
- (errmsg_internal("DH load buffer: %s",
- SSLerrmessage())));
+ (errmsg_internal("DH load buffer: %s",
+ SSLerrmessage())));
BIO_free(bio);
return dh;
@@ -749,7 +782,7 @@
* of a reasonable check to apply on Windows. (See also the data
* directory permission check in postmaster.c)
*/
-#if !defined(WIN32) && !defined(__CYGWIN__)
+#ifndef WIN32
if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) ||
buf.st_uid != geteuid())
ereport(FATAL,
@@ -760,8 +793,8 @@
#endif
if (!SSL_CTX_use_PrivateKey_file(SSL_context,
- SERVER_PRIVATE_KEY_FILE,
- SSL_FILETYPE_PEM))
+ SERVER_PRIVATE_KEY_FILE,
+ SSL_FILETYPE_PEM))
ereport(FATAL,
(errmsg("could not load private key file \"%s\": %s",
SERVER_PRIVATE_KEY_FILE, SSLerrmessage())));
@@ -810,9 +843,9 @@
X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
#else
ereport(LOG,
- (errmsg("SSL certificate revocation list file \"%s\" ignored",
- ROOT_CRL_FILE),
- errdetail("SSL library does not support certificate revocation lists.")));
+ (errmsg("SSL certificate revocation list file \"%s\" ignored",
+ ROOT_CRL_FILE),
+ errdetail("SSL library does not support certificate revocation lists.")));
#endif
else
{
@@ -887,9 +920,25 @@
case SSL_ERROR_WANT_WRITE:
#ifdef WIN32
pgwin32_waitforsinglesocket(SSL_get_fd(port->ssl),
- (err == SSL_ERROR_WANT_READ) ?
- FD_READ | FD_CLOSE | FD_ACCEPT : FD_WRITE | FD_CLOSE,
- INFINITE);
+ (err == SSL_ERROR_WANT_READ) ?
+ FD_READ | FD_CLOSE | FD_ACCEPT : FD_WRITE | FD_CLOSE,
+ INFINITE);
+#elif defined(__CYGWIN__)
+ {
+ fd_set rset;
+ int sel_res;
+ struct timeval tv;
+ FD_ZERO(&rset);
+ FD_SET(SSL_get_fd(port->ssl), &rset);
+ tv.tv_sec = 0;
+ tv.tv_usec = 500000;
+ sel_res = select(FD_SETSIZE,
+ (err == SSL_ERROR_WANT_READ) ? &rset : NULL,
+ (err == SSL_ERROR_WANT_READ) ? NULL : &rset,
+ NULL, &tv);
+ if (sel_res >= 0 || errno != EINTR)
+ break;
+ }
#endif
goto aloop;
case SSL_ERROR_SYSCALL:
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/backend/postmaster/pgstat.csrc/postgresql-8.3.3/src/backend/postmaster/pgstat.c
--- origsrc/postgresql-8.3.3/src/backend/postmaster/pgstat.c 2008-04-03 16:27:32.000000000 +0000
+++ src/postgresql-8.3.3/src/backend/postmaster/pgstat.c 2008-06-28 08:27:03.546875000 +0000
@@ -2160,7 +2160,7 @@
int len;
PgStat_Msg msg;
-#ifndef WIN32
+#if !defined(WIN32) || defined(__CYGWIN__)
#ifdef HAVE_POLL
struct pollfd input_fd;
#else
@@ -2231,7 +2231,7 @@
* Setup the descriptor set for select(2). Since only one bit in the set
* ever changes, we need not repeat FD_ZERO each time.
*/
-#if !defined(HAVE_POLL) && !defined(WIN32)
+#if !defined(HAVE_POLL) && (!defined(WIN32) || defined(__CYGWIN__))
FD_ZERO(&rfds);
#endif
@@ -2281,7 +2281,7 @@
* We use poll(2) if available, otherwise select(2). Win32 has its own
* implementation.
*/
-#ifndef WIN32
+#if !defined(WIN32) || defined(__CYGWIN__)
#ifdef HAVE_POLL
input_fd.fd = pgStatSock;
input_fd.events = POLLIN | POLLERR;
@@ -2321,7 +2321,7 @@
#endif /* HAVE_POLL */
#else /* WIN32 */
got_data = pgwin32_waitforsinglesocket(pgStatSock, FD_READ,
- PGSTAT_SELECT_TIMEOUT * 1000);
+ PGSTAT_SELECT_TIMEOUT * 1000);
#endif
/*
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/backend/postmaster/postmaster.csrc/postgresql-8.3.3/src/backend/postmaster/postmaster.c
--- origsrc/postgresql-8.3.3/src/backend/postmaster/postmaster.c 2008-01-11 00:54:09.000000000 +0000
+++ src/postgresql-8.3.3/src/backend/postmaster/postmaster.c 2008-06-28 08:27:03.546875000 +0000
@@ -349,6 +349,9 @@
HANDLE PostmasterHandle;
#endif
+#endif
+#ifdef EXEC_BACKEND
+
static pid_t backend_forkexec(Port *port);
static pid_t internal_forkexec(int argc, char *argv[], Port *port);
@@ -417,6 +420,7 @@
static void ShmemBackendArrayRemove(pid_t pid);
#endif /* EXEC_BACKEND */
+
#define StartupDataBase() StartChildProcess(StartupProcess)
#define StartBackgroundWriter() StartChildProcess(BgWriterProcess)
#define StartWalWriter() StartChildProcess(WalWriterProcess)
@@ -1072,7 +1076,7 @@
*
* XXX can we safely enable this check on Windows?
*/
-#if !defined(WIN32) && !defined(__CYGWIN__)
+#ifndef WIN32
if (stat_buf.st_uid != geteuid())
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
@@ -1094,7 +1098,7 @@
* be proper support for Unix-y file permissions. Need to think of a
* reasonable check to apply on Windows.
*/
-#if !defined(WIN32) && !defined(__CYGWIN__)
+#ifndef WIN32
if (stat_buf.st_mode & (S_IRWXG | S_IRWXO))
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/include/libpq/libpq-be.hsrc/postgresql-8.3.3/src/include/libpq/libpq-be.h
--- origsrc/postgresql-8.3.3/src/include/libpq/libpq-be.h 2008-01-01 19:45:58.000000000 +0000
+++ src/postgresql-8.3.3/src/include/libpq/libpq-be.h 2008-06-28 08:27:03.546875000 +0000
@@ -47,6 +47,9 @@
#ifdef ENABLE_SSPI
#define SECURITY_WIN32
+#ifdef __CYGWIN__
+#include <windows.h>
+#endif
#include <security.h>
#undef SECURITY_WIN32
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/include/libpq/libpq.hsrc/postgresql-8.3.3/src/include/libpq/libpq.h
--- origsrc/postgresql-8.3.3/src/include/libpq/libpq.h 2008-01-01 19:45:58.000000000 +0000
+++ src/postgresql-8.3.3/src/include/libpq/libpq.h 2008-06-28 08:27:03.546875000 +0000
@@ -20,6 +20,10 @@
#include "lib/stringinfo.h"
#include "libpq/libpq-be.h"
+#ifdef __CYGWIN__
+#undef WIN32
+#endif
+
/* ----------------
* PQArgBlock
* Information (pointer to array of this structure) required
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/include/miscadmin.hsrc/postgresql-8.3.3/src/include/miscadmin.h
--- origsrc/postgresql-8.3.3/src/include/miscadmin.h 2008-01-03 21:23:15.000000000 +0000
+++ src/postgresql-8.3.3/src/include/miscadmin.h 2008-06-28 08:27:03.546875000 +0000
@@ -78,7 +78,7 @@
/* in tcop/postgres.c */
extern void ProcessInterrupts(void);
-#ifndef WIN32
+#if !defined(WIN32) || defined(__CYGWIN__)
#define CHECK_FOR_INTERRUPTS() \
do { \
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/include/port/cygwin.hsrc/postgresql-8.3.3/src/include/port/cygwin.h
--- origsrc/postgresql-8.3.3/src/include/port/cygwin.h 2007-07-25 12:22:53.000000000 +0000
+++ src/postgresql-8.3.3/src/include/port/cygwin.h 2008-06-28 08:27:03.546875000 +0000
@@ -19,3 +19,10 @@
#define PGDLLIMPORT __declspec (dllimport)
#endif
+
+/*
+ * Always build with SSPI support. Keep it as a #define in case
+ * we want a switch to disable it sometime in the future.
+ */
+#define ENABLE_SSPI 1
+
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x
config.h-x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class'-x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x
'postgresql-8.2.0-1.cygport~'-x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x
'postgresql-8.2.9-1.cygport~'-x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x
'postgresql7.4-7.4.13-1.cygport~'-x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in-x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x
ltsugar.m4-x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x
symlink-tree-x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make
-xgnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in
-xintltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc
origsrc/postgresql-8.3.3/src/interfaces/libpq/libpq.rc.insrc/postgresql-8.3.3/src/interfaces/libpq/libpq.rc.in
--- origsrc/postgresql-8.3.3/src/interfaces/libpq/libpq.rc.in 2008-06-08 22:14:09.000000000 +0000
+++ src/postgresql-8.3.3/src/interfaces/libpq/libpq.rc.in 2008-06-28 08:27:03.546875000 +0000
@@ -19,7 +19,7 @@
VALUE "InternalName", "libpq\0"
VALUE "LegalCopyright", "Copyright (C) 2008\0"
VALUE "LegalTrademarks", "\0"
- VALUE "OriginalFilename", "libpq.dll\0"
+ VALUE "OriginalFilename", "cygpq.dll\0"
VALUE "ProductName", "PostgreSQL\0"
VALUE "ProductVersion", "8.3.3\0"
END
Reini Urban wrote: > Dave Page schrieb: >> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> >> wrote: >>> Yes. >>> >>> As in the cygwin build does build. Nobody really has verified if the fix >>> is needed there. But frankly, if you are likely to care about the >>> effects of this issue, you won't be running cygwin anyway. It's mostly a >>> dead platform for postgresql anyway, AFAICS we only keep it building for >>> legacy compatibility. Once it starts taking lots of resources to keep >>> building (which it doesn't now), I think we should just drop it >>> instead... > > "Dead" is interesting. We see a lot of cygwin users having postgresql > installed. Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. >> FWIW, the most recent packages from Cygwin themselves are 8.2.5. > > Update: 8.2.9 is latest. Good! > 8.3.x not because the new SSPI doesn't work yet. > > currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java > --with-ossp-uuid --with-ldap > (but ldap works okay with 8.2.9) > > currently testing is: --enable-nls --with-CXX --with-openssl --with-perl > --with-python --with-libxml --with-libxslt > > current cygwin patch in testing is attached. I assume this is a WIP and not actually for application, right? Please look it over because it contains a number of pure-whitespace changes that make it harder to read, and that will just end up being undone by pgindent at a later date anyway. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. There's also a number of: -#ifndef·WIN32 +#if·!defined(WIN32)·||·defined(__CYGWIN__) If I read that right, it shouldn't be necessary as long as the WIN32 define is not set on CYGWIN? And finally: -············VALUE·"OriginalFilename",·"libpq.dll\0" +············VALUE·"OriginalFilename",·"cygpq.dll\0" This obviously has to be done another way, because that change will affect the win32 platform as well... //Magnus
Magnus Hagander wrote: > > 8.3.x not because the new SSPI doesn't work yet. > > current cygwin patch in testing is attached. > > I assume this is a WIP and not actually for application, right? Please > look it over because it contains a number of pure-whitespace changes > that make it harder to read, and that will just end up being undone by > pgindent at a later date anyway. The patch also seems to hint that pgwin32_waitforsinglesocket needs a specific Cygwin implementation too (rather than patching every caller). -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Magnus Hagander schrieb: > Reini Urban wrote: >> Dave Page schrieb: >>> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> >>> wrote: >>>> Yes. >>>> >>>> As in the cygwin build does build. Nobody really has verified if the fix >>>> is needed there. But frankly, if you are likely to care about the >>>> effects of this issue, you won't be running cygwin anyway. It's mostly a >>>> dead platform for postgresql anyway, AFAICS we only keep it building for >>>> legacy compatibility. Once it starts taking lots of resources to keep >>>> building (which it doesn't now), I think we should just drop it >>>> instead... >> "Dead" is interesting. We see a lot of cygwin users having postgresql >> installed. > > Heh. Maybe not dead, but certainly not really alive either ;-) Given the > evidence in your patch that clearly 8.3 isn't quite up to speed on > cygwin, and nobody has really noticed until now. > > >>> FWIW, the most recent packages from Cygwin themselves are 8.2.5. >> Update: 8.2.9 is latest. > > Good! > >> 8.3.x not because the new SSPI doesn't work yet. >> >> currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java >> --with-ossp-uuid --with-ldap >> (but ldap works okay with 8.2.9) >> >> currently testing is: --enable-nls --with-CXX --with-openssl --with-perl >> --with-python --with-libxml --with-libxslt >> >> current cygwin patch in testing is attached. > > I assume this is a WIP and not actually for application, right? Please > look it over because it contains a number of pure-whitespace changes > that make it harder to read, and that will just end up being undone by > pgindent at a later date anyway. Sure. This is just the current status of my patch (still from 8.3beta2), nothing to actually submit. > I also notice this in auth.c: > +#ifdef·__CYGWIN__ > +#define·WIN32 > +#endif > > What is the need to change this for just one file? Seems very fragile - > the rest of our codebase assumes WIN32 != CYGWIN, and I think we should > keep that consistent. SSPI has some direct winapi calls to libsecure32 which are simpliest to declare by this cygwin == WIN32 declaration in the backend. For the client libpq this is not so easy, I still have troubles seperating this. > There's also a number of: > -#ifndef·WIN32 > +#if·!defined(WIN32)·||·defined(__CYGWIN__) > > If I read that right, it shouldn't be necessary as long as the WIN32 > define is not set on CYGWIN? This is only for the special case cygwin == WIN32. Just to be sure while testing I wrote it this way. > And finally: > -············VALUE·"OriginalFilename",·"libpq.dll\0" > +············VALUE·"OriginalFilename",·"cygpq.dll\0" > > This obviously has to be done another way, because that change will > affect the win32 platform as well... Sure :) This is only vendor private. -- Reini
Magnus Hagander wrote: > Heh. Maybe not dead, but certainly not really alive either ;-) Given the > evidence in your patch that clearly 8.3 isn't quite up to speed on > cygwin, and nobody has really noticed until now. > AIUI, only the gssapi stuff is broken. Most users are not likely to want it on Cygwin I should think. (And plenty of distros are still on 8.2 and earlier, anyway). What would be nice would be for Reini to set up a Cygwin buildfarm member that uses all the switches that the Cygwin distro wants to use. > > I also notice this in auth.c: > +#ifdef·__CYGWIN__ > +#define·WIN32 > +#endif > > What is the need to change this for just one file? Seems very fragile - > the rest of our codebase assumes WIN32 != CYGWIN, and I think we should > keep that consistent. > > > > Right. We have had significant grief from this in the past, and don't need to return there. If we need it to get correct behaviour from some header file, then it needs to be heavily commented and localised. But I bet there are other ways to get the right result - that's what we've tended to find in the past. cheers andrew
Andrew Dunstan schrieb: > Magnus Hagander wrote: >> Heh. Maybe not dead, but certainly not really alive either ;-) Given the >> evidence in your patch that clearly 8.3 isn't quite up to speed on >> cygwin, and nobody has really noticed until now. >> > > AIUI, only the gssapi stuff is broken. Most users are not likely to want > it on Cygwin I should think. (And plenty of distros are still on 8.2 and > earlier, anyway). Well, native windows users is a very nice to have. Actually a killer feature. > What would be nice would be for Reini to set up a Cygwin buildfarm > member that uses all the switches that the Cygwin distro wants to use. Without ENABLE_SSPI I just need --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt--with-ldap and these build out of the box. >> I also notice this in auth.c: >> +#ifdef·__CYGWIN__ >> +#define·WIN32 >> +#endif >> >> What is the need to change this for just one file? Seems very fragile - >> the rest of our codebase assumes WIN32 != CYGWIN, and I think we should >> keep that consistent. > > Right. We have had significant grief from this in the past, and don't > need to return there. If we need it to get correct behaviour from some > header file, then it needs to be heavily commented and localised. But I > bet there are other ways to get the right result - that's what we've > tended to find in the past. Ok, I copy then the required lines from WIN32. This was the shortest patch I could come up with and it worked nice for the auth backend, with SSPI enabled. -- Reini
Where are we on this patch? --------------------------------------------------------------------------- Reini Urban wrote: > Dave Page schrieb: > > On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote: > >> Yes. > >> > >> As in the cygwin build does build. Nobody really has verified if the fix > >> is needed there. But frankly, if you are likely to care about the > >> effects of this issue, you won't be running cygwin anyway. It's mostly a > >> dead platform for postgresql anyway, AFAICS we only keep it building for > >> legacy compatibility. Once it starts taking lots of resources to keep > >> building (which it doesn't now), I think we should just drop it instead... > > "Dead" is interesting. We see a lot of cygwin users having postgresql > installed. > > > FWIW, the most recent packages from Cygwin themselves are 8.2.5. > > Update: 8.2.9 is latest. > 8.3.x not because the new SSPI doesn't work yet. > > currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java > --with-ossp-uuid --with-ldap > (but ldap works okay with 8.2.9) > > currently testing is: --enable-nls --with-CXX --with-openssl --with-perl > --with-python --with-libxml --with-libxslt > > current cygwin patch in testing is attached. > -- > Reini Urban > postgresql cygwin maintainer > -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Where are we on this? The patch was not acceptable for several reasons; for one: > And finally: > -????????????VALUE?"OriginalFilename",?"libpq.dll\0" > +????????????VALUE?"OriginalFilename",?"cygpq.dll\0" > > This obviously has to be done another way, because that change will > affect the win32 platform as well... --------------------------------------------------------------------------- Reini Urban wrote: > Dave Page schrieb: > > On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote: > >> Yes. > >> > >> As in the cygwin build does build. Nobody really has verified if the fix > >> is needed there. But frankly, if you are likely to care about the > >> effects of this issue, you won't be running cygwin anyway. It's mostly a > >> dead platform for postgresql anyway, AFAICS we only keep it building for > >> legacy compatibility. Once it starts taking lots of resources to keep > >> building (which it doesn't now), I think we should just drop it instead... > > "Dead" is interesting. We see a lot of cygwin users having postgresql > installed. > > > FWIW, the most recent packages from Cygwin themselves are 8.2.5. > > Update: 8.2.9 is latest. > 8.3.x not because the new SSPI doesn't work yet. > > currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java > --with-ossp-uuid --with-ldap > (but ldap works okay with 8.2.9) > > currently testing is: --enable-nls --with-CXX --with-openssl --with-perl > --with-python --with-libxml --with-libxslt > > current cygwin patch in testing is attached. > -- > Reini Urban > postgresql cygwin maintainer > -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
If we have no plan to apply this patch, do we need to remove Cygwin as a supported platform? --------------------------------------------------------------------------- Bruce Momjian wrote: > > Where are we on this? The patch was not acceptable for several reasons; > for one: > > > And finally: > > -????????????VALUE?"OriginalFilename",?"libpq.dll\0" > > +????????????VALUE?"OriginalFilename",?"cygpq.dll\0" > > > > This obviously has to be done another way, because that change will > > affect the win32 platform as well... > > --------------------------------------------------------------------------- > > Reini Urban wrote: > > Dave Page schrieb: > > > On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote: > > >> Yes. > > >> > > >> As in the cygwin build does build. Nobody really has verified if the fix > > >> is needed there. But frankly, if you are likely to care about the > > >> effects of this issue, you won't be running cygwin anyway. It's mostly a > > >> dead platform for postgresql anyway, AFAICS we only keep it building for > > >> legacy compatibility. Once it starts taking lots of resources to keep > > >> building (which it doesn't now), I think we should just drop it instead... > > > > "Dead" is interesting. We see a lot of cygwin users having postgresql > > installed. > > > > > FWIW, the most recent packages from Cygwin themselves are 8.2.5. > > > > Update: 8.2.9 is latest. > > 8.3.x not because the new SSPI doesn't work yet. > > > > currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java > > --with-ossp-uuid --with-ldap > > (but ldap works okay with 8.2.9) > > > > currently testing is: --enable-nls --with-CXX --with-openssl --with-perl > > --with-python --with-libxml --with-libxslt > > > > current cygwin patch in testing is attached. > > -- > > Reini Urban > > postgresql cygwin maintainer > > > > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I'm confused. There is a Cygwin member of buildfarm, working quite happily. Can you point me to the exact patch in question, please? I thought we resolved the matter of stat() ages ago. cheers andrew Bruce Momjian wrote: > If we have no plan to apply this patch, do we need to remove Cygwin as a > supported platform? > > --------------------------------------------------------------------------- > > Bruce Momjian wrote: > >> Where are we on this? The patch was not acceptable for several reasons; >> for one: >> >> >>> And finally: >>> -????????????VALUE?"OriginalFilename",?"libpq.dll\0" >>> +????????????VALUE?"OriginalFilename",?"cygpq.dll\0" >>> >>> This obviously has to be done another way, because that change will >>> affect the win32 platform as well... >>> >> --------------------------------------------------------------------------- >> >> Reini Urban wrote: >> >>> Dave Page schrieb: >>> >>>> On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus@hagander.net> wrote: >>>> >>>>> Yes. >>>>> >>>>> As in the cygwin build does build. Nobody really has verified if the fix >>>>> is needed there. But frankly, if you are likely to care about the >>>>> effects of this issue, you won't be running cygwin anyway. It's mostly a >>>>> dead platform for postgresql anyway, AFAICS we only keep it building for >>>>> legacy compatibility. Once it starts taking lots of resources to keep >>>>> building (which it doesn't now), I think we should just drop it instead... >>>>> >>> "Dead" is interesting. We see a lot of cygwin users having postgresql >>> installed. >>> >>> >>>> FWIW, the most recent packages from Cygwin themselves are 8.2.5. >>>> >>> Update: 8.2.9 is latest. >>> 8.3.x not because the new SSPI doesn't work yet. >>> >>> currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java >>> --with-ossp-uuid --with-ldap >>> (but ldap works okay with 8.2.9) >>> >>> currently testing is: --enable-nls --with-CXX --with-openssl --with-perl >>> --with-python --with-libxml --with-libxslt >>> >>> current cygwin patch in testing is attached. >>> -- >>> Reini Urban >>> postgresql cygwin maintainer >>> >>> >> -- >> Bruce Momjian <bruce@momjian.us> http://momjian.us >> EnterpriseDB http://enterprisedb.com >> >> + If your life is a hard drive, Christ can be your backup. + >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers >> > >
Andrew Dunstan wrote: > > I'm confused. There is a Cygwin member of buildfarm, working quite > happily. Can you point me to the exact patch in question, please? I > thought we resolved the matter of stat() ages ago. http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> I'm confused. There is a Cygwin member of buildfarm, working quite >> happily. Can you point me to the exact patch in question, please? I >> thought we resolved the matter of stat() ages ago. >> > > http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at > > That patch is NOT about $subject. In fact, if you read that whole thread you will see here http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I conducted a test on Cygwin and found it was not suffering from the problem we fixed on WIN32. AFAICT Reini's patch is about fixing OpenSSL and possibly some other options on Cygwin. It was rejected because it had other problems, but is not indicative of a fundamental problem on Cygwin. There is no reason I am aware of that we should declare Cygwin no longer supported, no matter how much its continued existence apparently annoys a few people :-) . cheers andrew
Andrew Dunstan wrote: > > > Alvaro Herrera wrote: > > Andrew Dunstan wrote: > > > >> I'm confused. There is a Cygwin member of buildfarm, working quite > >> happily. Can you point me to the exact patch in question, please? I > >> thought we resolved the matter of stat() ages ago. > >> > > > > http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at > > > > > > That patch is NOT about $subject. In fact, if you read that whole thread > you will see here > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I > conducted a test on Cygwin and found it was not suffering from the > problem we fixed on WIN32. > > AFAICT Reini's patch is about fixing OpenSSL and possibly some other > options on Cygwin. It was rejected because it had other problems, but is > not indicative of a fundamental problem on Cygwin. There is no reason I > am aware of that we should declare Cygwin no longer supported, no matter > how much its continued existence apparently annoys a few people :-) . Oh, good, thanks for clearing that up. So should we just document that OpenSSL doesn't work on Cygwin and call this item closed? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Andrew Dunstan wrote: > >> Alvaro Herrera wrote: >> >>> Andrew Dunstan wrote: >>> >>> >>>> I'm confused. There is a Cygwin member of buildfarm, working quite >>>> happily. Can you point me to the exact patch in question, please? I >>>> thought we resolved the matter of stat() ages ago. >>>> >>>> >>> http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at >>> >>> >>> >> That patch is NOT about $subject. In fact, if you read that whole thread >> you will see here >> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I >> conducted a test on Cygwin and found it was not suffering from the >> problem we fixed on WIN32. >> >> AFAICT Reini's patch is about fixing OpenSSL and possibly some other >> options on Cygwin. It was rejected because it had other problems, but is >> not indicative of a fundamental problem on Cygwin. There is no reason I >> am aware of that we should declare Cygwin no longer supported, no matter >> how much its continued existence apparently annoys a few people :-) . >> > > Oh, good, thanks for clearing that up. So should we just document that > OpenSSL doesn't work on Cygwin and call this item closed? > > This item should be closed. We should see if Reini can submit an acceptable patch for OpenSSL. cheers andrew
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > Andrew Dunstan wrote: > > > >> Alvaro Herrera wrote: > >> > >>> Andrew Dunstan wrote: > >>> > >>> > >>>> I'm confused. There is a Cygwin member of buildfarm, working quite > >>>> happily. Can you point me to the exact patch in question, please? I > >>>> thought we resolved the matter of stat() ages ago. > >>>> > >>>> > >>> http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at > >>> > >>> > >>> > >> That patch is NOT about $subject. In fact, if you read that whole thread > >> you will see here > >> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I > >> conducted a test on Cygwin and found it was not suffering from the > >> problem we fixed on WIN32. > >> > >> AFAICT Reini's patch is about fixing OpenSSL and possibly some other > >> options on Cygwin. It was rejected because it had other problems, but is > >> not indicative of a fundamental problem on Cygwin. There is no reason I > >> am aware of that we should declare Cygwin no longer supported, no matter > >> how much its continued existence apparently annoys a few people :-) . > >> > > > > Oh, good, thanks for clearing that up. So should we just document that > > OpenSSL doesn't work on Cygwin and call this item closed? > > > > > > This item should be closed. We should see if Reini can submit an > acceptable patch for OpenSSL. I have documented that OpenSSL is not supported for Cygwin. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian schrieb: > Andrew Dunstan wrote: >> >> Bruce Momjian wrote: >>> Andrew Dunstan wrote: >>> >>>> Alvaro Herrera wrote: >>>> >>>>> Andrew Dunstan wrote: >>>>> >>>>> >>>>>> I'm confused. There is a Cygwin member of buildfarm, working quite >>>>>> happily. Can you point me to the exact patch in question, please? I >>>>>> thought we resolved the matter of stat() ages ago. >>>>>> >>>>>> >>>>> http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at >>>>> >>>>> >>>>> >>>> That patch is NOT about $subject. In fact, if you read that whole thread >>>> you will see here >>>> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I >>>> conducted a test on Cygwin and found it was not suffering from the >>>> problem we fixed on WIN32. >>>> >>>> AFAICT Reini's patch is about fixing OpenSSL and possibly some other >>>> options on Cygwin. It was rejected because it had other problems, but is >>>> not indicative of a fundamental problem on Cygwin. There is no reason I >>>> am aware of that we should declare Cygwin no longer supported, no matter >>>> how much its continued existence apparently annoys a few people :-) . >>>> >>> Oh, good, thanks for clearing that up. So should we just document that >>> OpenSSL doesn't work on Cygwin and call this item closed? >>> >>> >> This item should be closed. We should see if Reini can submit an >> acceptable patch for OpenSSL. > > I have documented that OpenSSL is not supported for Cygwin. Excuse me? openssl works fine on cygwin, even without the testing patch which was attached. This patch only tried to optimize openssl socket handling equivalent to WIN32. Please revert that documentation. The current configure args of the official postgresql packages are: --enable-nls --with-openssl --with-perl --with-python --with-ldap The problem is just that SSPI auth does not compile on cygwin. -- Reini Urban http://phpwiki.org/ http://murbreak.at/