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:
Show quoted text
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
Show quoted text
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
Show quoted text
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
Attachments:
postgresql-8.3.3-1.src.patchtext/x-patch; name=postgresql-8.3.3-1.src.patchDownload
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x 'postgresql-8.2.0-1.cygport~' -x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x 'postgresql-8.2.9-1.cygport~' -x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x 'postgresql7.4-7.4.13-1.cygport~' -x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/auth.c src/postgresql-8.3.3/src/backend/libpq/auth.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/auth.c 2008-02-08 17:58:46.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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c src/postgresql-8.3.3/src/backend/libpq/be-secure.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-01-01 19:45:49.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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/postmaster/pgstat.c src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/postmaster/postmaster.c src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/include/libpq/libpq-be.h src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/include/libpq/libpq.h src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/include/miscadmin.h src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/include/port/cygwin.h src/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 -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/interfaces/libpq/libpq.rc.in src/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-libxsltcurrent 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
+#endifWhat 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-libxsltcurrent 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 +#endifWhat 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 +#endifWhat 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 +#endifWhat 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-libxsltcurrent 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-libxsltcurrent 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-libxsltcurrent 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:
Show quoted text
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-libxsltcurrent 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/