Re: [PATCHES] Compiling libpq with VisualC

2004-06-24 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes:
 elog.h is included in postgres.h, which is included in many 
 src/port/*.c. Many of them are pretty straight, not requiring any 
 backend specific stuff, so the attached patch will change postgres.h to 
 c.h for most of them.

Applied.  I did the sys/time.h stuff the standard Autoconf way, however.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Compiling libpq with VisualC

2004-06-20 Thread Andreas Pflug
Tom wrote:
It's there to declare struct timeval, and I'm fairly certain that diking
it out of the header would break things on some platforms.  Where does
Windows define struct timeval?
   

struct timeval is defined in winsock.h under vc6.
I'm checking for _MSC_VER now.
Agreed.  We define FRONTEND when compiling libpq.  Please test for that
and send another patch.
 

elog.h is included in postgres.h, which is included in many 
src/port/*.c. Many of them are pretty straight, not requiring any 
backend specific stuff, so the attached patch will change postgres.h to 
c.h for most of them.

Regards,
Andreas
Index: include/libpq/libpq-be.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.45
diff -u -r1.45 libpq-be.h
--- include/libpq/libpq-be.h21 May 2004 05:08:04 -  1.45
+++ include/libpq/libpq-be.h20 Jun 2004 09:19:54 -
@@ -18,7 +18,12 @@
 #ifndef LIBPQ_BE_H
 #define LIBPQ_BE_H
 
+#if _MSC_VER  0
+/* struct timeval is declared in winsock.h */
+#else
 #include sys/time.h
+#endif
+
 
 #ifdef USE_SSL
 #include openssl/ssl.h
Index: port/getopt.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/getopt.c,v
retrieving revision 1.5
diff -u -r1.5 getopt.c
--- port/getopt.c   4 Aug 2003 00:43:33 -   1.5
+++ port/getopt.c   20 Jun 2004 09:19:55 -
@@ -32,7 +32,7 @@
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  */
 
-#include postgres.h
+#include c.h
 
 
 #if defined(LIBC_SCCS)  !defined(lint)
Index: port/getrusage.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/getrusage.c,v
retrieving revision 1.4
diff -u -r1.4 getrusage.c
--- port/getrusage.c29 Nov 2003 19:52:13 -  1.4
+++ port/getrusage.c20 Jun 2004 09:19:55 -
@@ -16,7 +16,7 @@
 #include stdio.h
 #include errno.h
 
-#include postgres.h
+#include c.h
 #include rusagestub.h
 
 /* This code works on:
Index: port/gettimeofday.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/gettimeofday.c,v
retrieving revision 1.4
diff -u -r1.4 gettimeofday.c
--- port/gettimeofday.c 21 May 2004 05:08:05 -  1.4
+++ port/gettimeofday.c 20 Jun 2004 09:19:55 -
@@ -23,7 +23,7 @@
  * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
  */
 
-#include postgres.h
+#include c.h
 
 #include sys/time.h
 
Index: port/kill.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/kill.c,v
retrieving revision 1.1
diff -u -r1.1 kill.c
--- port/kill.c 27 May 2004 13:08:57 -  1.1
+++ port/kill.c 20 Jun 2004 09:19:55 -
@@ -14,7 +14,7 @@
  *-
  */
 
-#include postgres.h
+#include c.h
 
 #ifdef WIN32
 /* signal sending */
Index: port/noblock.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/noblock.c,v
retrieving revision 1.1
diff -u -r1.1 noblock.c
--- port/noblock.c  10 Mar 2004 21:12:49 -  1.1
+++ port/noblock.c  20 Jun 2004 09:19:55 -
@@ -12,7 +12,7 @@
  *-
  */
 
-#include postgres.h
+#include c.h
 
 #include sys/types.h
 #include fcntl.h
Index: port/pgsleep.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/pgsleep.c,v
retrieving revision 1.3
diff -u -r1.3 pgsleep.c
--- port/pgsleep.c  12 Apr 2004 16:19:18 -  1.3
+++ port/pgsleep.c  20 Jun 2004 09:19:56 -
@@ -10,7 +10,7 @@
  *
  *-
  */
-#include postgres.h
+#include c.h
 
 #include unistd.h
 #include sys/time.h
Index: port/pgstrcasecmp.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/pgstrcasecmp.c,v
retrieving revision 1.1
diff -u -r1.1 pgstrcasecmp.c
--- port/pgstrcasecmp.c 7 May 2004 00:24:59 -   1.1
+++ port/pgstrcasecmp.c 20 Jun 2004 09:19:56 -
@@ -20,7 +20,7 @@
  *
  *-
  */
-#include postgres.h
+#include c.h
 
 #include ctype.h
 
Index: port/pipe.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/pipe.c,v
retrieving revision 1.5
diff -u -r1.5 pipe.c
--- port/pipe.c 11 Jun 2004 03:48:35 -  1.5
+++ port/pipe.c 20 Jun 2004 09:19:56 -
@@ -15,7 +15,7 @@
  *-
  */
 
-#include postgres.h
+#include c.h
 
 #ifdef WIN32
 int
Index: port/sprompt.c

Re: [PATCHES] Compiling libpq with VisualC

2004-06-19 Thread Andreas Pflug
Two minor tweaks:
sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it 
isn't used in Linux either; libpq will compile without it. All usages of 
gettimeofday throughout the backend don't seem connection related, so 
libpq-be.h seems an odd place to include it.

ERROR in elog.h has conflicts with a win32 defined macro; #undef WIN32 
solves the conflict (or not including elog.h for libpq purposes would do 
too)

Regards,
Andreas
Index: include/libpq/libpq-be.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v
retrieving revision 1.45
diff -u -r1.45 libpq-be.h
--- include/libpq/libpq-be.h21 May 2004 05:08:04 -  1.45
+++ include/libpq/libpq-be.h19 Jun 2004 19:46:52 -
@@ -18,7 +18,10 @@
 #ifndef LIBPQ_BE_H
 #define LIBPQ_BE_H
 
+#ifndef WIN32
 #include sys/time.h
+#endif
+
 
 #ifdef USE_SSL
 #include openssl/ssl.h

Index: include/utils/elog.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/utils/elog.h,v
retrieving revision 1.68
diff -u -r1.68 elog.h
--- include/utils/elog.h5 Apr 2004 03:02:10 -   1.68
+++ include/utils/elog.h19 Jun 2004 19:46:53 -
@@ -14,6 +14,10 @@
 #ifndef ELOG_H
 #define ELOG_H
 
+#ifdef ERROR
+#undef ERROR/* possible conflict in win32 */
+#endif
+
 /* Error level codes */
 #define DEBUG5 10  /* Debugging messages, in categories of
 * decreasing detail. 
*/

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Compiling libpq with VisualC

2004-06-19 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes:
 sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it 
 isn't used in Linux either; libpq will compile without it.

It's there to declare struct timeval, and I'm fairly certain that diking
it out of the header would break things on some platforms.  Where does
Windows define struct timeval?
 
 +#ifndef WIN32
  #include sys/time.h
 +#endif

Could we please use HAVE_SYS_TIME_H, rather than creating an unnecessary
platform specificity?

  #ifndef ELOG_H
  #define ELOG_H
 
 +#ifdef ERROR
 +#undef ERROR/* possible conflict in win32 */
 +#endif
 +
  /* Error level codes */

This seems likely to break anything expecting the Win32 definition
of ERROR.  Can we look at not including elog.h in frontend builds,
instead?  I can't think of any reason for frontend code to need it.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] Compiling libpq with VisualC

2004-06-19 Thread Bruce Momjian
Tom Lane wrote:
 Andreas Pflug [EMAIL PROTECTED] writes:
  sys/time.h in libpq-be.h isn't present on win32 vc6. Apparently, it 
  isn't used in Linux either; libpq will compile without it.
 
 It's there to declare struct timeval, and I'm fairly certain that diking
 it out of the header would break things on some platforms.  Where does
 Windows define struct timeval?
  
  +#ifndef WIN32
   #include sys/time.h
  +#endif
 
 Could we please use HAVE_SYS_TIME_H, rather than creating an unnecessary
 platform specificity?

The problem is that they are building from win32.mak, and don't run
configure at all.  Mingw does have it so we can't just skip including
it.  I think we should test for the MS compiler in this case.  Please
test for _MSC_VER instead of WIN32 and let us know how it works.

   #ifndef ELOG_H
   #define ELOG_H
  
  +#ifdef ERROR
  +#undef ERROR/* possible conflict in win32 */
  +#endif
  +
   /* Error level codes */
 
 This seems likely to break anything expecting the Win32 definition
 of ERROR.  Can we look at not including elog.h in frontend builds,
 instead?  I can't think of any reason for frontend code to need it.

Agreed.  We define FRONTEND when compiling libpq.  Please test for that
and send another patch.

Thanks.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Andreas Pflug
Bruce Momjian wrote:
I have looked over this patch.  I noticed this:

-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(init_mutex, NULL);
+}
While this might work using your pthread compatibility implementation
using CreateMutex(), it will not work on a native pthread implementation
because you can only call pthread_mutex_init() once.  Your code allows
two threads to both call it.
 

I don't really think so. That mutex_initialized is a globally static 
variable, not a thread local one. Thread interruption between testing 
mutex_initialized and setting it is very unlikely and still wouldn't do 
much harm if it actually does happen.

Also, do you not have the problem with SIGPIPE from send(), so you don't
need set/get_thread_specific()?
 

There's no SIGPIPE under win32, thus no problem.
Regards,
Andreas

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Manfred Spraul
Andreas Pflug wrote:
I don't really think so. That mutex_initialized is a globally static 
variable, not a thread local one. Thread interruption between testing 
mutex_initialized and setting it is very unlikely and still wouldn't 
do much harm if it actually does happen.

Very unlikely is not a good argument. And you haven't considered 
multiprocessor systems. They aren't that rare: all newer Pentium 4 
systems have two logical cores.
The harm would be a failed connection attempt - I don't think that this 
is acceptable.

Hmm. Is libpq a .DLL? Then you could initialize the mutex in DllMain(). 
Otherwise create a C++ class with one instance and a constructor. Then 
initialize the mutex from the constructor.

--
   Manfred
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Bruce Momjian
Manfred Spraul wrote:
 Andreas Pflug wrote:
 
  I don't really think so. That mutex_initialized is a globally static 
  variable, not a thread local one. Thread interruption between testing 
  mutex_initialized and setting it is very unlikely and still wouldn't 
  do much harm if it actually does happen.
 
 Very unlikely is not a good argument. And you haven't considered 
 multiprocessor systems. They aren't that rare: all newer Pentium 4 
 systems have two logical cores.
 The harm would be a failed connection attempt - I don't think that this 
 is acceptable.

Agreed.  My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that.  If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the Unix safe.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Andreas Pflug
Bruce Momjian wrote:

Agreed.  My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that.  If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the Unix safe.
 

Ok, so here's the win32 workaround with the unix stuff left untouched.
There's no memory interlocking api in win32 that wouldn't need some 
initializing api call itself, so we'd have to go for assembly level 
test-and-set code or introduce a mandatory global libpq initializing 
api. Considering the probably quite low usage of kerberos/ssl together 
with threads under win32, and the very low probability of two 
threads/processors (!) trying to initiate a connection at the same time, 
it doesn't seem to be worth the compiler hassle with assembly inline.

Regards,
Andreas

Index: interfaces/libpq/fe-connect.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.274
diff -u -r1.274 fe-connect.c
--- interfaces/libpq/fe-connect.c   10 Jun 2004 22:26:24 -  1.274
+++ interfaces/libpq/fe-connect.c   11 Jun 2004 17:33:34 -
@@ -882,11 +882,13 @@
const char *node = NULL;
int ret;
 #ifdef ENABLE_THREAD_SAFETY
+#ifndef WIN32
static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT;
 
/* Check only on first connection request */
pthread_once(check_sigpipe_once, check_sigpipe_handler);
 #endif
+#endif
 
if (!conn)
return 0;
@@ -3183,11 +3185,22 @@
 }
 
 static pgthreadlock_t default_threadlock;
+
 static void
 default_threadlock(int acquire)
 {
 #ifdef ENABLE_THREAD_SAFETY
+#ifndef WIN32
static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
+#else
+   static pthread_mutex_t singlethread_lock;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(singlethread_lock, NULL);
+}
+#endif
if (acquire)
pthread_mutex_lock(singlethread_lock);
else
Index: interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.41
diff -u -r1.41 fe-secure.c
--- interfaces/libpq/fe-secure.c3 Jun 2004 00:13:19 -   1.41
+++ interfaces/libpq/fe-secure.c11 Jun 2004 17:33:36 -
@@ -864,8 +864,17 @@
 init_ssl_system(PGconn *conn)
 {
 #ifdef ENABLE_THREAD_SAFETY
-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+#ifndef WIN32
+static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
+#else
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(init_mutex, NULL);
+}
+#endif
pthread_mutex_lock(init_mutex);

if (pq_initssllib  pq_lockarray == NULL) {
@@ -1171,6 +1180,7 @@
 
 
 #ifdef ENABLE_THREAD_SAFETY
+#ifndef WIN32
 /*
  * Check SIGPIPE handler and perhaps install our own.
  */
@@ -1210,6 +1220,7 @@
if (!PQinSend())
exit(128 + SIGPIPE);/* typical return value for SIG_DFL */
 }
+#endif
 #endif
  
 /*
Index: interfaces/libpq/win32.mak
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
retrieving revision 1.24
diff -u -r1.24 win32.mak
--- interfaces/libpq/win32.mak  4 Jun 2004 13:30:04 -   1.24
+++ interfaces/libpq/win32.mak  11 Jun 2004 17:33:37 -
@@ -74,21 +74,25 @@
[EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib
[EMAIL PROTECTED] $(INTDIR)\wchar.obj
[EMAIL PROTECTED] $(INTDIR)\encnames.obj
+   [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj
 
 
 
-config: ..\..\include\pg_config.h pg_config_paths.h
+config: ..\..\include\pg_config.h pthread.h pg_config_paths.h
 
 ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
 
+pthread.h: pthread.h.win32
+   copy pthread.h.win32 pthread.h
+
 pg_config_paths.h: win32.mak
echo #define SYSCONFDIR  pg_config_paths.h
 
 $(OUTDIR) :
 if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
 
-CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /D FRONTEND $(DEBUGDEF) /D\
+CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /I. /D FRONTEND $(DEBUGDEF) /D\
  WIN32 /D _WINDOWS /Fp$(INTDIR)\libpq.pch /YX\
  /Fo$(INTDIR)\\ /Fd$(INTDIR)\\ /FD /c  /D HAVE_VSNPRINTF /D HAVE_STRDUP
 
@@ -127,7 +131,8 @@
$(INTDIR)\fe-secure.obj \
$(INTDIR)\pqexpbuffer.obj \
$(INTDIR)\wchar.obj \
-   $(INTDIR)\encnames.obj
+   

Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Manfred Spraul
Andreas Pflug wrote:
Bruce Momjian wrote:

Agreed.  My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that.  If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the Unix safe.
 

Ok, so here's the win32 workaround with the unix stuff left untouched.
There's no memory interlocking api in win32 that wouldn't need some 
initializing api call itself, so we'd have to go for assembly level 
test-and-set code.
Wrong. There are portable test-and-set functions in the Win32 SDK: for 
example InterlockedCompareExchange. They operate on ints and do not need 
initialization.

or introduce a mandatory global libpq initializing api.
There is a third option: Add one C++ file and use the constructor to 
initialize the mutex. VisualC is always a C++ compiler, thus C++ support 
shouldn't be an issue. I've attached an example app.

Considering the probably quite low usage of kerberos/ssl together with 
threads under win32, and the very low probability of two 
threads/processors (!) trying to initiate a connection at the same 
time, it doesn't seem to be worth the compiler hassle with assembly 
inline.

This argument is insane: Given enough installations, even a very low 
probability will cause failures.

But this is a minor point, I think the patch should go in and I'll write 
with a proposal to close the race, either based on 
InterlockedCompareExchange or on a C++ file.

--
   Manfred
#include stdio.h
#include stdlib.h


int g_mutex;


extern C int main(void) {
	printf(in main. Value now %d.\n, g_mutex);
}

class init_me
{
public:
		init_me::init_me(void)
	{
		g_mutex = 99; /* CreateMutex(), or whatever. */
	}
};

static class init_me instance_one;


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Bruce Momjian

Can you put that in the new pthread file that needs to be added for Win32?

---

Manfred Spraul wrote:
 Andreas Pflug wrote:
 
  Bruce Momjian wrote:
 
 
 
  Agreed.  My pthread book says pthread_mutex_init() should be called only
  once, and we have to guarantee that.  If the Windows implentation allows
  it to be called multiple times, just create a function to be called only
  by Win32 that does that and leave the Unix safe.
 
   
 
  Ok, so here's the win32 workaround with the unix stuff left untouched.
  There's no memory interlocking api in win32 that wouldn't need some 
  initializing api call itself, so we'd have to go for assembly level 
  test-and-set code.
 
 Wrong. There are portable test-and-set functions in the Win32 SDK: for 
 example InterlockedCompareExchange. They operate on ints and do not need 
 initialization.
 
  or introduce a mandatory global libpq initializing api.
 
 There is a third option: Add one C++ file and use the constructor to 
 initialize the mutex. VisualC is always a C++ compiler, thus C++ support 
 shouldn't be an issue. I've attached an example app.
 
  Considering the probably quite low usage of kerberos/ssl together with 
  threads under win32, and the very low probability of two 
  threads/processors (!) trying to initiate a connection at the same 
  time, it doesn't seem to be worth the compiler hassle with assembly 
  inline.
 
 This argument is insane: Given enough installations, even a very low 
 probability will cause failures.
 
 But this is a minor point, I think the patch should go in and I'll write 
 with a proposal to close the race, either based on 
 InterlockedCompareExchange or on a C++ file.
 
 --
 Manfred


-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Andreas Pflug
Manfred Spraul wrote:
Wrong. There are portable test-and-set functions in the Win32 SDK: for 
example InterlockedCompareExchange. They operate on ints and do not 
need initialization.
'k, missed that one. Lets use it.
There is a third option: Add one C++ file and use the constructor to 
initialize the mutex. VisualC is always a C++ compiler, thus C++ 
support shouldn't be an issue.
Our code is potentially not only VC.
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Bruce Momjian
Andreas Pflug wrote:
 Manfred Spraul wrote:
 
 
  Wrong. There are portable test-and-set functions in the Win32 SDK: for 
  example InterlockedCompareExchange. They operate on ints and do not 
  need initialization.
 
 'k, missed that one. Lets use it.
 
 
  There is a third option: Add one C++ file and use the constructor to 
  initialize the mutex. VisualC is always a C++ compiler, thus C++ 
  support shouldn't be an issue.
 
 Our code is potentially not only VC.

True, MinGW and Cygwin.  Can we do the C solution?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Bruce Momjian

This patch has to be redone to make it thread-safe.

---


Andreas Pflug wrote:
 The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled 
 with Visual C. Two additional files will supply the needed pthread stuff.
 
 There's no SIGPIPE for native win32, so there are some #IFNDEF WIN32 to 
 skip installing a signal handler for this. I'm not sure if this is going 
 to show conflicts for CYGWIN or other unix-like builds on win32 
 platforms, i.e. if WIN32 is defined in such cases or not; please check.
 
 Note: the previously posted win32.mak patch is superseded by this.
 
 Regards,
 Andreas

 Index: win32.mak
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
 retrieving revision 1.23
 diff -u -r1.23 win32.mak
 --- win32.mak 3 Jun 2004 00:11:13 -   1.23
 +++ win32.mak 4 Jun 2004 13:26:39 -
 @@ -74,19 +74,25 @@
   [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib
   [EMAIL PROTECTED] $(INTDIR)\wchar.obj
   [EMAIL PROTECTED] $(INTDIR)\encnames.obj
 + [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj
  
  
  
 -config: ..\..\include\pg_config.h
 +config: ..\..\include\pg_config.h pthread.h pg_config_paths.h
  
  ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
   copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
  
 +pthread.h: pthread.h.win32
 + copy pthread.h.win32 pthread.h
 +
 +pg_config_paths.h: win32.mak
 + echo #define SYSCONFDIR  pg_config_paths.h
  
  $(OUTDIR) :
  if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
  
 -CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /D FRONTEND $(DEBUGDEF) /D\
 +CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /I. /D FRONTEND $(DEBUGDEF) /D\
   WIN32 /D _WINDOWS /Fp$(INTDIR)\libpq.pch /YX\
   /Fo$(INTDIR)\\ /Fd$(INTDIR)\\ /FD /c  /D HAVE_VSNPRINTF /D HAVE_STRDUP
  
 @@ -95,6 +101,10 @@
  SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
  !ENDIF
  
 +!IFDEF ENABLE_THREAD_SAFETY
 +CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
 +!ENDIF
 +
  CPP_SBRS=.
  
  LIB32=link.exe -lib
 @@ -121,7 +131,8 @@
   $(INTDIR)\fe-secure.obj \
   $(INTDIR)\pqexpbuffer.obj \
   $(INTDIR)\wchar.obj \
 - $(INTDIR)\encnames.obj
 + $(INTDIR)\encnames.obj \
 + $(INTDIR)\pthread-win32.obj
  
  
  RSC_PROJ=/l 0x409 /fo$(INTDIR)\libpq.res
 Index: fe-connect.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
 retrieving revision 1.272
 diff -u -r1.272 fe-connect.c
 --- fe-connect.c  3 Jun 2004 00:07:38 -   1.272
 +++ fe-connect.c  4 Jun 2004 13:26:43 -
 @@ -882,11 +882,13 @@
   const char *node = NULL;
   int ret;
  #ifdef ENABLE_THREAD_SAFETY
 +#ifndef WIN32
   static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT;
  
   /* Check only on first connection request */
   pthread_once(check_sigpipe_once, check_sigpipe_handler);
  #endif
 +#endif
  
   if (!conn)
   return 0;
 @@ -3187,7 +3189,13 @@
  default_threadlock(int acquire)
  {
  #ifdef ENABLE_THREAD_SAFETY
 - static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
 + static pthread_mutex_t singlethread_lock;
 +static int mutex_initialized = 0;
 +if (!mutex_initialized)
 +{
 +mutex_initialized = 1;
 +pthread_mutex_init(singlethread_lock, NULL);
 +}
   if (acquire)
   pthread_mutex_lock(singlethread_lock);
   else
 Index: fe-secure.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
 retrieving revision 1.41
 diff -u -r1.41 fe-secure.c
 --- fe-secure.c   3 Jun 2004 00:13:19 -   1.41
 +++ fe-secure.c   4 Jun 2004 13:26:45 -
 @@ -864,8 +864,13 @@
  init_ssl_system(PGconn *conn)
  {
  #ifdef ENABLE_THREAD_SAFETY
 -static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
 -
 +static pthread_mutex_t init_mutex;
 +static int mutex_initialized = 0;
 +if (!mutex_initialized)
 +{
 +mutex_initialized = 1;
 +pthread_mutex_init(init_mutex, NULL);
 +}
   pthread_mutex_lock(init_mutex);
   
   if (pq_initssllib  pq_lockarray == NULL) {
 @@ -1171,6 +1176,7 @@
  
  
  #ifdef ENABLE_THREAD_SAFETY
 +#ifndef WIN32
  /*
   *   Check SIGPIPE handler and perhaps install our own.
   */
 @@ -1210,6 +1216,7 @@
   if (!PQinSend())
   exit(128 + SIGPIPE);/* typical return value for SIG_DFL */
  }
 +#endif
  #endif
   
  /*

 /*-
 *
 * pthread-win32.c
 *partial pthread implementation for win32
 *
 * Copyright (c) 2004, PostgreSQL Global 

Re: [PATCHES] Compiling libpq with VisualC

2004-06-11 Thread Bruce Momjian

Sorry, I accidentally bounced this to the lists.

The patch needs redesign and has been removed from the patch queue.

---

Andreas Pflug wrote:
 The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled 
 with Visual C. Two additional files will supply the needed pthread stuff.
 
 There's no SIGPIPE for native win32, so there are some #IFNDEF WIN32 to 
 skip installing a signal handler for this. I'm not sure if this is going 
 to show conflicts for CYGWIN or other unix-like builds on win32 
 platforms, i.e. if WIN32 is defined in such cases or not; please check.
 
 Note: the previously posted win32.mak patch is superseded by this.
 
 Regards,
 Andreas

 Index: win32.mak
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
 retrieving revision 1.23
 diff -u -r1.23 win32.mak
 --- win32.mak 3 Jun 2004 00:11:13 -   1.23
 +++ win32.mak 4 Jun 2004 13:26:39 -
 @@ -74,19 +74,25 @@
   [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib
   [EMAIL PROTECTED] $(INTDIR)\wchar.obj
   [EMAIL PROTECTED] $(INTDIR)\encnames.obj
 + [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj
  
  
  
 -config: ..\..\include\pg_config.h
 +config: ..\..\include\pg_config.h pthread.h pg_config_paths.h
  
  ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
   copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
  
 +pthread.h: pthread.h.win32
 + copy pthread.h.win32 pthread.h
 +
 +pg_config_paths.h: win32.mak
 + echo #define SYSCONFDIR  pg_config_paths.h
  
  $(OUTDIR) :
  if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
  
 -CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /D FRONTEND $(DEBUGDEF) /D\
 +CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /I. /D FRONTEND $(DEBUGDEF) /D\
   WIN32 /D _WINDOWS /Fp$(INTDIR)\libpq.pch /YX\
   /Fo$(INTDIR)\\ /Fd$(INTDIR)\\ /FD /c  /D HAVE_VSNPRINTF /D HAVE_STRDUP
  
 @@ -95,6 +101,10 @@
  SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
  !ENDIF
  
 +!IFDEF ENABLE_THREAD_SAFETY
 +CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
 +!ENDIF
 +
  CPP_SBRS=.
  
  LIB32=link.exe -lib
 @@ -121,7 +131,8 @@
   $(INTDIR)\fe-secure.obj \
   $(INTDIR)\pqexpbuffer.obj \
   $(INTDIR)\wchar.obj \
 - $(INTDIR)\encnames.obj
 + $(INTDIR)\encnames.obj \
 + $(INTDIR)\pthread-win32.obj
  
  
  RSC_PROJ=/l 0x409 /fo$(INTDIR)\libpq.res
 Index: fe-connect.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
 retrieving revision 1.272
 diff -u -r1.272 fe-connect.c
 --- fe-connect.c  3 Jun 2004 00:07:38 -   1.272
 +++ fe-connect.c  4 Jun 2004 13:26:43 -
 @@ -882,11 +882,13 @@
   const char *node = NULL;
   int ret;
  #ifdef ENABLE_THREAD_SAFETY
 +#ifndef WIN32
   static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT;
  
   /* Check only on first connection request */
   pthread_once(check_sigpipe_once, check_sigpipe_handler);
  #endif
 +#endif
  
   if (!conn)
   return 0;
 @@ -3187,7 +3189,13 @@
  default_threadlock(int acquire)
  {
  #ifdef ENABLE_THREAD_SAFETY
 - static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
 + static pthread_mutex_t singlethread_lock;
 +static int mutex_initialized = 0;
 +if (!mutex_initialized)
 +{
 +mutex_initialized = 1;
 +pthread_mutex_init(singlethread_lock, NULL);
 +}
   if (acquire)
   pthread_mutex_lock(singlethread_lock);
   else
 Index: fe-secure.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
 retrieving revision 1.41
 diff -u -r1.41 fe-secure.c
 --- fe-secure.c   3 Jun 2004 00:13:19 -   1.41
 +++ fe-secure.c   4 Jun 2004 13:26:45 -
 @@ -864,8 +864,13 @@
  init_ssl_system(PGconn *conn)
  {
  #ifdef ENABLE_THREAD_SAFETY
 -static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
 -
 +static pthread_mutex_t init_mutex;
 +static int mutex_initialized = 0;
 +if (!mutex_initialized)
 +{
 +mutex_initialized = 1;
 +pthread_mutex_init(init_mutex, NULL);
 +}
   pthread_mutex_lock(init_mutex);
   
   if (pq_initssllib  pq_lockarray == NULL) {
 @@ -1171,6 +1176,7 @@
  
  
  #ifdef ENABLE_THREAD_SAFETY
 +#ifndef WIN32
  /*
   *   Check SIGPIPE handler and perhaps install our own.
   */
 @@ -1210,6 +1216,7 @@
   if (!PQinSend())
   exit(128 + SIGPIPE);/* typical return value for SIG_DFL */
  }
 +#endif
  #endif
   
  /*

 /*-
 *
 * pthread-win32.c
 *partial pthread 

Re: [PATCHES] Compiling libpq with VisualC

2004-06-10 Thread Bruce Momjian

I have looked over this patch.  I noticed this:

-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(init_mutex, NULL);
+}

While this might work using your pthread compatibility implementation
using CreateMutex(), it will not work on a native pthread implementation
because you can only call pthread_mutex_init() once.  Your code allows
two threads to both call it.

Now, how to fix it?  You need some kind of pthread_once() call or
somehow set up a critical section that will prevent two threads from
doing the initialization, but there is no method using your API to
create the critical section without creating a lock first.

I am thinking we need to put your initialization code in #ifdef WIN32
and keep the native pthread code unchanged.

Also, do you not have the problem with SIGPIPE from send(), so you don't
need set/get_thread_specific()?

---

Andreas Pflug wrote:
 The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled 
 with Visual C. Two additional files will supply the needed pthread stuff.
 
 There's no SIGPIPE for native win32, so there are some #IFNDEF WIN32 to 
 skip installing a signal handler for this. I'm not sure if this is going 
 to show conflicts for CYGWIN or other unix-like builds on win32 
 platforms, i.e. if WIN32 is defined in such cases or not; please check.
 
 Note: the previously posted win32.mak patch is superseded by this.
 
 Regards,
 Andreas

 Index: win32.mak
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
 retrieving revision 1.23
 diff -u -r1.23 win32.mak
 --- win32.mak 3 Jun 2004 00:11:13 -   1.23
 +++ win32.mak 4 Jun 2004 13:26:39 -
 @@ -74,19 +74,25 @@
   [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib
   [EMAIL PROTECTED] $(INTDIR)\wchar.obj
   [EMAIL PROTECTED] $(INTDIR)\encnames.obj
 + [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj
  
  
  
 -config: ..\..\include\pg_config.h
 +config: ..\..\include\pg_config.h pthread.h pg_config_paths.h
  
  ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
   copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
  
 +pthread.h: pthread.h.win32
 + copy pthread.h.win32 pthread.h
 +
 +pg_config_paths.h: win32.mak
 + echo #define SYSCONFDIR  pg_config_paths.h
  
  $(OUTDIR) :
  if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
  
 -CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /D FRONTEND $(DEBUGDEF) /D\
 +CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /I. /D FRONTEND $(DEBUGDEF) /D\
   WIN32 /D _WINDOWS /Fp$(INTDIR)\libpq.pch /YX\
   /Fo$(INTDIR)\\ /Fd$(INTDIR)\\ /FD /c  /D HAVE_VSNPRINTF /D HAVE_STRDUP
  
 @@ -95,6 +101,10 @@
  SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
  !ENDIF
  
 +!IFDEF ENABLE_THREAD_SAFETY
 +CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
 +!ENDIF
 +
  CPP_SBRS=.
  
  LIB32=link.exe -lib
 @@ -121,7 +131,8 @@
   $(INTDIR)\fe-secure.obj \
   $(INTDIR)\pqexpbuffer.obj \
   $(INTDIR)\wchar.obj \
 - $(INTDIR)\encnames.obj
 + $(INTDIR)\encnames.obj \
 + $(INTDIR)\pthread-win32.obj
  
  
  RSC_PROJ=/l 0x409 /fo$(INTDIR)\libpq.res
 Index: fe-connect.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
 retrieving revision 1.272
 diff -u -r1.272 fe-connect.c
 --- fe-connect.c  3 Jun 2004 00:07:38 -   1.272
 +++ fe-connect.c  4 Jun 2004 13:26:43 -
 @@ -882,11 +882,13 @@
   const char *node = NULL;
   int ret;
  #ifdef ENABLE_THREAD_SAFETY
 +#ifndef WIN32
   static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT;
  
   /* Check only on first connection request */
   pthread_once(check_sigpipe_once, check_sigpipe_handler);
  #endif
 +#endif
  
   if (!conn)
   return 0;
 @@ -3187,7 +3189,13 @@
  default_threadlock(int acquire)
  {
  #ifdef ENABLE_THREAD_SAFETY
 - static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
 + static pthread_mutex_t singlethread_lock;
 +static int mutex_initialized = 0;
 +if (!mutex_initialized)
 +{
 +mutex_initialized = 1;
 +pthread_mutex_init(singlethread_lock, NULL);
 +}
   if (acquire)
   pthread_mutex_lock(singlethread_lock);
   else
 Index: fe-secure.c
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
 retrieving revision 1.41
 diff -u -r1.41 

Re: [PATCHES] Compiling libpq with VisualC

2004-06-04 Thread Andreas Pflug
Bruce Momjian wrote:
Andreas Pflug wrote:
 

Bruce Momjian wrote:
   


 

fe-connect.c:
- pg_config_paths.h isn't available. SYSCONFDIR is already defined so 
fe-connect.c doesn't need to include that.
patch appended


 

This shouldn't be needed anymore.  Where is SYSCONFDIR coming from?  Is
it from some Win32 include file?  It should only be coming from
pg_config_paths.h now.
 

It's defined in pg_config.h.win32, which is copied to pg_config.h. 
There's no pg_config_paths.h for win32, and I wonder if the code which 
uses SYSCONFDIR is of any use for win32.
   

Thanks.  Removed.  I never saw that because the file has a .win32
extension and my search tools didn't look in there.
 

Well, that doesn't work like this. As I already wrote, there's no 
SYSCONFDIR, and if there was it can't have any sensible value for win32 
clients. SYSCONFDIR as of pg_config.h.win32 version 1.13 was just a 
dummy to make the compiler happy. Now there's no SYSCONFDIR around, and 
no pg_config_paths.h either...

The attached patch will create a dummy pg_config_paths.h. Additionally, 
ENABLE_THREAD_SAFETY is supported by the makefile (but not by the 
sources, which need some rework)

Regards,
Andreas

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


Re: [PATCHES] Compiling libpq with VisualC

2004-06-04 Thread Andreas Pflug
Andreas Pflug wrote:
The attached patch will create a dummy pg_config_paths.h. 
Additionally, ENABLE_THREAD_SAFETY is supported by the makefile (but 
not by the sources, which need some rework)

Now including the patch...
Regards,
Andreas
Index: win32.mak
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
retrieving revision 1.23
diff -u -r1.23 win32.mak
--- win32.mak   3 Jun 2004 00:11:13 -   1.23
+++ win32.mak   4 Jun 2004 08:22:50 -
@@ -77,11 +77,13 @@
 
 
 
-config: ..\..\include\pg_config.h
+config: ..\..\include\pg_config.h pg_config_paths.h
 
 ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
 
+pg_config_paths.h: win32.mak
+   echo #define SYSCONFDIR  pg_config_paths.h
 
 $(OUTDIR) :
 if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
@@ -93,6 +95,10 @@
 !IFDEF USE_SSL
 CPP_PROJ=$(CPP_PROJ) /D USE_SSL
 SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
+!ENDIF
+
+!IFDEF ENABLE_THREAD_SAFETY
+CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
 !ENDIF
 
 CPP_SBRS=.



---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Compiling libpq with VisualC

2004-06-04 Thread Bruce Momjian

Patch applied.  I didn't realize that file was for win32 _client_
compiles, and I didn't realize it had no pg_config_paths.h.

---

Andreas Pflug wrote:
 Bruce Momjian wrote:
 
 Andreas Pflug wrote:
   
 
 Bruce Momjian wrote:
 
 
 
  
 
   
 
 fe-connect.c:
 - pg_config_paths.h isn't available. SYSCONFDIR is already defined so 
 fe-connect.c doesn't need to include that.
 patch appended
  
 
   
 
 This shouldn't be needed anymore.  Where is SYSCONFDIR coming from?  Is
 it from some Win32 include file?  It should only be coming from
 pg_config_paths.h now.
  
 
   
 
 It's defined in pg_config.h.win32, which is copied to pg_config.h. 
 There's no pg_config_paths.h for win32, and I wonder if the code which 
 uses SYSCONFDIR is of any use for win32.
 
 
 
 Thanks.  Removed.  I never saw that because the file has a .win32
 extension and my search tools didn't look in there.
   
 
 Well, that doesn't work like this. As I already wrote, there's no 
 SYSCONFDIR, and if there was it can't have any sensible value for win32 
 clients. SYSCONFDIR as of pg_config.h.win32 version 1.13 was just a 
 dummy to make the compiler happy. Now there's no SYSCONFDIR around, and 
 no pg_config_paths.h either...
 
 The attached patch will create a dummy pg_config_paths.h. Additionally, 
 ENABLE_THREAD_SAFETY is supported by the makefile (but not by the 
 sources, which need some rework)
 
 Regards,
 Andreas
 
 
 
 ---(end of broadcast)---
 TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] Compiling libpq with VisualC

2004-06-04 Thread Andreas Pflug
The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled 
with Visual C. Two additional files will supply the needed pthread stuff.

There's no SIGPIPE for native win32, so there are some #IFNDEF WIN32 to 
skip installing a signal handler for this. I'm not sure if this is going 
to show conflicts for CYGWIN or other unix-like builds on win32 
platforms, i.e. if WIN32 is defined in such cases or not; please check.

Note: the previously posted win32.mak patch is superseded by this.
Regards,
Andreas
Index: win32.mak
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/win32.mak,v
retrieving revision 1.23
diff -u -r1.23 win32.mak
--- win32.mak   3 Jun 2004 00:11:13 -   1.23
+++ win32.mak   4 Jun 2004 13:26:39 -
@@ -74,19 +74,25 @@
[EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib
[EMAIL PROTECTED] $(INTDIR)\wchar.obj
[EMAIL PROTECTED] $(INTDIR)\encnames.obj
+   [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj
 
 
 
-config: ..\..\include\pg_config.h
+config: ..\..\include\pg_config.h pthread.h pg_config_paths.h
 
 ..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
 
+pthread.h: pthread.h.win32
+   copy pthread.h.win32 pthread.h
+
+pg_config_paths.h: win32.mak
+   echo #define SYSCONFDIR  pg_config_paths.h
 
 $(OUTDIR) :
 if not exist $(OUTDIR)/$(NULL) mkdir $(OUTDIR)
 
-CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /D FRONTEND $(DEBUGDEF) /D\
+CPP_PROJ=/nologo /W3 /GX $(OPT) /I ..\..\include /I. /D FRONTEND $(DEBUGDEF) /D\
  WIN32 /D _WINDOWS /Fp$(INTDIR)\libpq.pch /YX\
  /Fo$(INTDIR)\\ /Fd$(INTDIR)\\ /FD /c  /D HAVE_VSNPRINTF /D HAVE_STRDUP
 
@@ -95,6 +101,10 @@
 SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
 !ENDIF
 
+!IFDEF ENABLE_THREAD_SAFETY
+CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
+!ENDIF
+
 CPP_SBRS=.
 
 LIB32=link.exe -lib
@@ -121,7 +131,8 @@
$(INTDIR)\fe-secure.obj \
$(INTDIR)\pqexpbuffer.obj \
$(INTDIR)\wchar.obj \
-   $(INTDIR)\encnames.obj
+   $(INTDIR)\encnames.obj \
+   $(INTDIR)\pthread-win32.obj
 
 
 RSC_PROJ=/l 0x409 /fo$(INTDIR)\libpq.res
Index: fe-connect.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.272
diff -u -r1.272 fe-connect.c
--- fe-connect.c3 Jun 2004 00:07:38 -   1.272
+++ fe-connect.c4 Jun 2004 13:26:43 -
@@ -882,11 +882,13 @@
const char *node = NULL;
int ret;
 #ifdef ENABLE_THREAD_SAFETY
+#ifndef WIN32
static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT;
 
/* Check only on first connection request */
pthread_once(check_sigpipe_once, check_sigpipe_handler);
 #endif
+#endif
 
if (!conn)
return 0;
@@ -3187,7 +3189,13 @@
 default_threadlock(int acquire)
 {
 #ifdef ENABLE_THREAD_SAFETY
-   static pthread_mutex_t singlethread_lock = PTHREAD_MUTEX_INITIALIZER;
+   static pthread_mutex_t singlethread_lock;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(singlethread_lock, NULL);
+}
if (acquire)
pthread_mutex_lock(singlethread_lock);
else
Index: fe-secure.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.41
diff -u -r1.41 fe-secure.c
--- fe-secure.c 3 Jun 2004 00:13:19 -   1.41
+++ fe-secure.c 4 Jun 2004 13:26:45 -
@@ -864,8 +864,13 @@
 init_ssl_system(PGconn *conn)
 {
 #ifdef ENABLE_THREAD_SAFETY
-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+{
+mutex_initialized = 1;
+pthread_mutex_init(init_mutex, NULL);
+}
pthread_mutex_lock(init_mutex);

if (pq_initssllib  pq_lockarray == NULL) {
@@ -1171,6 +1176,7 @@
 
 
 #ifdef ENABLE_THREAD_SAFETY
+#ifndef WIN32
 /*
  * Check SIGPIPE handler and perhaps install our own.
  */
@@ -1210,6 +1216,7 @@
if (!PQinSend())
exit(128 + SIGPIPE);/* typical return value for SIG_DFL */
 }
+#endif
 #endif
  
 /*
/*-
*
* pthread-win32.c
*partial pthread implementation for win32
*
* Copyright (c) 2004, PostgreSQL Global Development Group
* IDENTIFICATION
*   $PostgreSQL: $ 
*
*-
*/


#include windows.h
#include pthread.h

HANDLE pthread_self()
{
   return GetCurrentThread();
}

void 

Re: [PATCHES] Compiling libpq with VisualC

2004-06-03 Thread Andreas Pflug
Bruce Momjian wrote:
 

fe-connect.c:
- pg_config_paths.h isn't available. SYSCONFDIR is already defined so 
fe-connect.c doesn't need to include that.
patch appended
 

This shouldn't be needed anymore.  Where is SYSCONFDIR coming from?  Is
it from some Win32 include file?  It should only be coming from
pg_config_paths.h now.
 

It's defined in pg_config.h.win32, which is copied to pg_config.h. 
There's no pg_config_paths.h for win32, and I wonder if the code which 
uses SYSCONFDIR is of any use for win32.

Regards,
Andreas

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] Compiling libpq with VisualC

2004-06-03 Thread Bruce Momjian
Andreas Pflug wrote:
 Bruce Momjian wrote:
 
   
 
 fe-connect.c:
 - pg_config_paths.h isn't available. SYSCONFDIR is already defined so 
 fe-connect.c doesn't need to include that.
 patch appended
   
 
 
 This shouldn't be needed anymore.  Where is SYSCONFDIR coming from?  Is
 it from some Win32 include file?  It should only be coming from
 pg_config_paths.h now.
   
 
 It's defined in pg_config.h.win32, which is copied to pg_config.h. 
 There's no pg_config_paths.h for win32, and I wonder if the code which 
 uses SYSCONFDIR is of any use for win32.

Thanks.  Removed.  I never saw that because the file has a .win32
extension and my search tools didn't look in there.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Compiling libpq with VisualC

2004-06-02 Thread Bruce Momjian
Bruce Momjian wrote:
 
 I noticed that SYSCONFDIR will also be an issue for relocatable installs
 just like localedir.  I will address them in the same way either as an
 environment variable or libpq function call to set the location.

Fixed.

  
  fe-connect.c:
  - pg_config_paths.h isn't available. SYSCONFDIR is already defined so 
  fe-connect.c doesn't need to include that.
  patch appended

This shouldn't be needed anymore.  Where is SYSCONFDIR coming from?  Is
it from some Win32 include file?  It should only be coming from
pg_config_paths.h now.

  win32.mak:
  - pg_config.h must be generated
  - port/pgstrcasecmp.c is needed
  - port/path.c is not needed
  - the current cvs version includes some bogus cr characters, when 
  checking out with wincvs the file will contain several cr cr lf lines 
  which will confuse nmake.
  
  Because the last problem might be difficult to handle as diff, I 
  attached win32.mak as complete file, with all cr stripped so it may be 
  committed safely with any cvs client.

Added.  Thanks.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match