Re: [PATCHES] Compiling libpq with VisualC
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);/* t
Re: [PATCHES] Compiling libpq with VisualC
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
>
Re: [PATCHES] Compiling libpq with VisualC
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
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
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
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
#include
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] pg_ctl using START with paths needing quotes
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
This applied patch changes the way pg_ctl starts on Win32.
Using START, it is not possible to quote the executable name, who's
directory might have spaces:
This is a really ugly hack (I take the blame since I gave Bruce the
idea). There are a few things to note:
. the .bat file should probably be created in the data dir - that's
about the only place that we should be guaranteed we can write.
In that case, haven't we simply moved the spaces problem from the
executable directory to the data directory?
Yep. That code is all gone now that we have the right fix, use:
START "" "executable"
For the record, and in case we need to use it in future, here's what I
got working in pg_ctl.c for starting without any shell call required
(lacks error checking).
cheers
andrew
#ifdef WIN32
char exepath[MAXPGPATH];
STARTUPINFO si;
PROCESS_INFORMATION pi;
bool rval;
int null_fd, log_fd;
int save_stdin, save_stdout, save_stderr;
save_stdin = _dup(fileno(stdin));
ZeroMemory(&si,sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
null_fd = open("nul",O_RDONLY,0);
dup2(null_fd, fileno(stdin));
if (log_file != NULL)
{
save_stdout = _dup(fileno(stdout));
save_stderr = _dup(fileno(stderr));
log_fd = open(log_file,O_WRONLY|O_CREAT|O_APPEND,0700);
dup2(log_fd, fileno(stdout));
dup2(log_fd ,fileno(stderr));
}
snprintf(exepath,MAXPGPATH,"%s",postgres_path);
snprintf(cmd,MAXPGPATH,"\"%s\" %s",postgres_path,post_opts);
rval = CreateProcess(exepath,cmd,NULL,NULL,true,0,NULL,NULL,&si,&pi);
if (rval == 0)
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
}
dup2(save_stdin, fileno(stdin));
close(null_fd);
if (log_file != NULL)
{
dup2(save_stdout,fileno(stdout));
dup2(save_stderr,fileno(stderr));
close(log_fd);
}
return (rval == 0);
#else
---(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] [HACKERS] serverlog function (log_destination file)
Tom Lane wrote:
This has got portability issues (fopen("ab"))
My doc says b is ignored on ansi systems, and recommends using it. Do
you have other experiences?
and I don't care for its
use of malloc in preference to palloc either.
Do we already have an applicable memory context in the postmaster at
that early stage of initialization?
Also, pg_logfile() will dump core if LogFileName returns null.
How that?
char *filename=LogFileName();
if (filename)
{
...
free(filename);
}
The bigger issue though is whether this is useful at all, if you cannot
solve the file rotation issue (and I don't think you can). As
implemented, the secondary log file cannot be truncated without
restarting the postmaster. I think that reduces it from a possibly
useful feature to a useless toy.
This patch isn't trying to be better on logfile handling than the
default stderr redirection behavior, besides being able to access it
through the postmaster. Seems you insist to name this a toy, many users
don't.
(The fact that pg_logfile_length
returns int and not something wider is pretty silly in this connection.)
2GB logfile seems pretty big...
Regards,
Andreas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Fix for erroneous warning on Shutdown
Patch rejected, asking for more research. --- Simon Riggs wrote: > > Minor patch to correct erroneous warning in cvs tip, believed to be a > very minor regression. > > When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint, > the shutdown code in the bgwriter (which has does checkpointing) would > issue the erroneous message: > > LOG: checkpoints are occurring too frequently (%d seconds apart) > HINT: Consider increasing the configuration parameter > "checkpoint_segments". > > Clearly, this should only occur when specific checkpoint requests have > been made, shutdown checkpoints should not be included in the warning. > > Best regards, Simon Riggs [ Attachment, skipping... ] > > ---(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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Fix for erroneous warning on Shutdown
Simon Riggs <[EMAIL PROTECTED]> writes: > Minor patch to correct erroneous warning in cvs tip, believed to be a > very minor regression. This patch is wrong; it effectively disables the warning altogether. > When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint, > the shutdown code in the bgwriter (which has does checkpointing) would > issue the erroneous message: I don't think so ... the shutdown path doesn't go through this code. Could you take another look at the cause of what you saw? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > The attached patch has the default filename issue fixed, and
> > documentation. Since I don't have a doc build system functional, there
> > might be tag mismatches or other typos; please check. IMHO this should
> > be committed without waiting for log rotation stuff.
>
> This has got portability issues (fopen("ab")) and I don't care for its
> use of malloc in preference to palloc either. Also, pg_logfile() will
> dump core if LogFileName returns null.
>
> The bigger issue though is whether this is useful at all, if you cannot
> solve the file rotation issue (and I don't think you can). As
> implemented, the secondary log file cannot be truncated without
> restarting the postmaster. I think that reduces it from a possibly
> useful feature to a useless toy. (The fact that pg_logfile_length
> returns int and not something wider is pretty silly in this connection.)
>
> My vote is not to apply until and unless something that can rotate the
> logfile is demonstrated ...
Agreed. Lets see where it goes.
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
Andreas Pflug <[EMAIL PROTECTED]> writes:
> The attached patch has the default filename issue fixed, and
> documentation. Since I don't have a doc build system functional, there
> might be tag mismatches or other typos; please check. IMHO this should
> be committed without waiting for log rotation stuff.
This has got portability issues (fopen("ab")) and I don't care for its
use of malloc in preference to palloc either. Also, pg_logfile() will
dump core if LogFileName returns null.
The bigger issue though is whether this is useful at all, if you cannot
solve the file rotation issue (and I don't think you can). As
implemented, the secondary log file cannot be truncated without
restarting the postmaster. I think that reduces it from a possibly
useful feature to a useless toy. (The fact that pg_logfile_length
returns int and not something wider is pretty silly in this connection.)
My vote is not to apply until and unless something that can rotate the
logfile is demonstrated ...
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] pg_ctl using START with paths needing quotes
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > Bruce Momjian wrote: > >> This applied patch changes the way pg_ctl starts on Win32. > >> > >> Using START, it is not possible to quote the executable name, who's > >> directory might have spaces: > > > > This is a really ugly hack (I take the blame since I gave Bruce the > > idea). There are a few things to note: > > > . the .bat file should probably be created in the data dir - that's > > about the only place that we should be guaranteed we can write. > > In that case, haven't we simply moved the spaces problem from the > executable directory to the data directory? Yep. That code is all gone now that we have the right fix, use: START "" "executable" -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
Bruce Momjian wrote:
I was thinking of close/reopen so log files
could be rotated.
Log file rotation is fine, if we find a consensus quite soon how to
implement it... Seems as if I might find some time to implement it until
feature freeze.
The attached patch has the default filename issue fixed, and
documentation. Since I don't have a doc build system functional, there
might be tag mismatches or other typos; please check. IMHO this should
be committed without waiting for log rotation stuff.
Regards,
Andreas
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.206
diff -u -r1.206 func.sgml
--- doc/src/sgml/func.sgml 2 Jun 2004 21:34:49 - 1.206
+++ doc/src/sgml/func.sgml 11 Jun 2004 17:58:35 -
@@ -7308,6 +7308,53 @@
columns do not have OIDs of their own.
+
+ pg_logfile
+
+
+ pg_logfile_length
+
+
+The functions shown in
+ deal with the server log file if configured with log_destination
+ file.
+previously stored with the COMMENT command. A
+null value is returned if no comment could be found matching the
+specified parameters.
+
+
+
+Server Logfile Functions
+
+
+ Name Return Type
Description
+
+
+
+
+
pg_logfile(size_int4,
offset_int4)
+ cstring
+ get a part of the server log file
+
+
+ pg_logfile_length()
+ int4
+ return the current length of the server log file
+
+
+
+
+
+The pg_logfile function will return the
+ contents of the server log file, limited by the size
+ parameter. If size is NULL, a server internal limit (currently
+ 5) is applied. The position parameter determines the
+ starting position of the server log chunk to be returned. A
+ positive number or 0 will be counted from the start of the file,
+ a negative number from the end; if NULL, -size is assumed
+ (i.e. the tail of the log file).
+
+
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.266
diff -u -r1.266 runtime.sgml
--- doc/src/sgml/runtime.sgml 10 Jun 2004 22:26:17 - 1.266
+++ doc/src/sgml/runtime.sgml 11 Jun 2004 17:58:46 -
@@ -1721,14 +1721,25 @@
PostgreSQL supports several methods
-for loggning, including stderr and
-syslog. On Windows,
-eventlog is also supported. Set this
+for logging, including stderr,
+file and syslog.
+ On Windows, eventlog is also supported. Set this
option to a list of desired log destinations separated by a
comma. The default is to log to stderr
only. This option must be set at server start.
+
+
+
+ log_filename (string)
+
+
+ This option sets the target filename for the log destination
+ file option. It may be specified as absolute
+ path or relative to the cluster directory.
+
+
Index: src/backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.403
diff -u -r1.403 postmaster.c
--- src/backend/postmaster/postmaster.c 11 Jun 2004 03:54:43 - 1.403
+++ src/backend/postmaster/postmaster.c 11 Jun 2004 17:58:52 -
@@ -532,6 +532,9 @@
/* If timezone is not set, determine what the OS uses */
pg_timezone_initialize();
+/* open alternate logfile, if any */
+ LogFileOpen();
+
#ifdef EXEC_BACKEND
write_nondefault_variables(PGC_POSTMASTER);
#endif
Index: src/backend/storage/ipc/ipc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/ipc/ipc.c,v
retrieving revision 1.87
diff -u -r1.87 ipc.c
--- src/backend/storage/ipc/ipc.c 12 Dec 2003 18:45:09 - 1.87
+++ src/backend/storage/ipc/ipc.c 11 Jun 2004 17:58:52 -
@@ -111,6 +111,8 @@
on_proc_exit_list[on_proc_exit_index].arg);
elog(DEBUG3, "exit(%d)", code);
+
+ LogFileClose();
exit(code);
}
Index: src/backend/utils/adt/misc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/misc.c,v
retrieving revision 1.34
diff -u -r1.34 misc.c
--- src/backend/utils/adt/misc.c2 Jun 2004 21:29:29 - 1.34
+++ src/backend/utils/adt/misc.c11 Jun 2004 17:58:58 -
@@ -103,3 +103,70 @@
{
PG_RETURN_INT32(pg_signal_backend(PG_GETARG_INT
Re: [PATCHES] pg_ctl using START with paths needing quotes
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> This applied patch changes the way pg_ctl starts on Win32. >> >> Using START, it is not possible to quote the executable name, who's >> directory might have spaces: > > This is a really ugly hack (I take the blame since I gave Bruce the > idea). There are a few things to note: > . the .bat file should probably be created in the data dir - that's > about the only place that we should be guaranteed we can write. In that case, haven't we simply moved the spaces problem from the executable directory to the data directory? regards, tom lane ---(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] pg_ctl using START with paths needing quotes
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Bruce Momjian wrote: This applied patch changes the way pg_ctl starts on Win32. Using START, it is not possible to quote the executable name, who's directory might have spaces: This is a really ugly hack (I take the blame since I gave Bruce the idea). There are a few things to note: . the .bat file should probably be created in the data dir - that's about the only place that we should be guaranteed we can write. In that case, haven't we simply moved the spaces problem from the executable directory to the data directory? Yes. you're right. The hack is gone now so it's moot. cheers andrew ---(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] translation updates pt_BR
Hi Peter, > Euler Taveira de Oliveira wrote: > > Here are some updates for REL7_4. > > Please apply it before release 7.4.3. > > http://www.ufgnet.ufg.br/euler/pg_update_7_4_3.tar.gz > > Installed. Brazil takes the lead... Thanks. And the docs are in progress too. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Compiling libpq with VisualC
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)\w
Re: [PATCHES] path.c char[strlen("xxx")] not portable
Patch applied. The only reason I used strlen is because sizeof a string
is one more than the strlen().
---
Zeugswetter Andreas SB SD wrote:
>
> strlen inside variable declaration is not portable C (AIX):
>
> char env_path[MAXPGPATH + strlen("PGLOCALEDIR=")];
>
> use sizeof instead.
>
> Please apply to current
>
> Andreas
Content-Description: path.c.locale.patch
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
--
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 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
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] pg_ctl using START with paths needing quotes
Andrew Dunstan wrote: > > This is a really ugly hack (I take the blame since I gave Bruce the > idea). There are a few things to note: > > . the .bat file should probably be created in the data dir - that's > about the only place that we should be guaranteed we can write. > . the command should be preceded by '@' to suppress echoing > . the whole command, including redirections should go inside the .bat > file, so that pg_ctl just issues 'start /b foo.bat' > > There are still things to clean up in pg_ctl, e.g. its handling of > relative paths to the data dir. Hack removed. -- 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]
[PATCHES] Fix for Win32 START
After digging, I found START can accept a quoted executable name if you
put a title of "" before it. I have remove the batch file hack and
documented this requirement.
--
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
Index: src/bin/pg_ctl/pg_ctl.c
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.15
diff -c -c -r1.15 pg_ctl.c
*** src/bin/pg_ctl/pg_ctl.c 11 Jun 2004 04:17:21 - 1.15
--- src/bin/pg_ctl/pg_ctl.c 11 Jun 2004 16:32:45 -
***
*** 221,291
* to pass everything to a shell to process them.
*/
charcmd[MAXPGPATH];
- int ret;
- char*pgexec = postgres_path;
- #ifdef WIN32
/*
!* Win32 has a problem with the interaction between START and system().
!* There is no way to quote the executable name passed to START.
!* Therefore, we put the executable name in a temporary batch file
!* and run it via START.
*/
- chartmp[MAXPGPATH] = "C:\\PG_CTL_XX", /* good location? */
- bat[MAXPGPATH];
- int fd = mkstemp(tmp);
-
- if (fd == -1)
- {
- fprintf(stderr, _("%s: cannot create batch file %s to start server:
%s\n"),
- progname, tmp, strerror(errno));
- exit(1);
- }
- write(fd, postgres_path, strlen(postgres_path));
- write(fd, "\n", 1);
- close(fd);
-
- strcpy(bat, tmp);
- strcat(bat, ".BAT");
- pgexec = bat;
- if (rename(tmp, bat) == -1)
- {
- fprintf(stderr, _("%s: cannot rename batch file %s to %s: %s\n"),
- progname, tmp, bat, strerror(errno));
- unlink(tmp);
- exit(1);
- }
- #endif
-
if (log_file != NULL)
- /* Win32 needs START /B rather than "&" */
#ifndef WIN32
snprintf(cmd, MAXPGPATH, "%s\"%s\" %s < \"%s\" >> \"%s\" 2>&1 &%s",
#else
! snprintf(cmd, MAXPGPATH, "%sSTART /B %s %s < \"%s\" >> \"%s\" 2>&1%s",
#endif
!SYSTEMQUOTE, pgexec, post_opts, DEVNULL, log_file,
SYSTEMQUOTE);
else
#ifndef WIN32
snprintf(cmd, MAXPGPATH, "%s\"%s\" %s < \"%s\" 2>&1 &%s",
#else
! snprintf(cmd, MAXPGPATH, "%sSTART /B %s %s < \"%s\" 2>&1%s",
#endif
!SYSTEMQUOTE, pgexec, post_opts, DEVNULL, SYSTEMQUOTE);
!
! ret = system(cmd);
! #ifdef WIN32
! /* We are unlinking it while it is running, but that should be OK */
! if (unlink(bat))
! {
! fprintf(stderr, _("%s: cannot remove batch file %s: %s\n"),
! progname, bat, strerror(errno));
! exit(1);
! }
! #endif
! return ret;
}
--- 221,253
* to pass everything to a shell to process them.
*/
charcmd[MAXPGPATH];
/*
!* Win32 needs START /B rather than "&".
!*
!* Win32 has a problem with START and quoted executable names.
!* You must add a "" as the title at the beginning so you can quote
!* the executable name:
!* http://www.winnetmag.com/Article/ArticleID/14589/14589.html
!* http://dev.remotenetworktechnology.com/cmd/cmdfaq.htm
*/
if (log_file != NULL)
#ifndef WIN32
snprintf(cmd, MAXPGPATH, "%s\"%s\" %s < \"%s\" >> \"%s\" 2>&1 &%s",
#else
! snprintf(cmd, MAXPGPATH, "%sSTART /B \"\" \"%s\" %s < \"%s\" >> \"%s\"
2>&1%s",
#endif
!SYSTEMQUOTE, postgres_path, post_opts, DEVNULL,
log_file,
SYSTEMQUOTE);
else
#ifndef WIN32
snprintf(cmd, MAXPGPATH, "%s\"%s\" %s < \"%s\" 2>&1 &%s",
#else
! snprintf(cmd, MAXPGPATH, "%sSTART /B \"\" \"%s\" %s < \"%s\" 2>&1%s",
#endif
!SYSTEMQUOTE, postgres_path, post_opts, DEVNULL,
SYSTEMQUOTE);
! return system(cmd);
}
---(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
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])
[PATCHES] Fix for erroneous warning on Shutdown
Minor patch to correct erroneous warning in cvs tip, believed to be a
very minor regression.
When a shutdown was requested within CHECKPOINT_SECONDS of a checkpoint,
the shutdown code in the bgwriter (which has does checkpointing) would
issue the erroneous message:
LOG: checkpoints are occurring too frequently (%d seconds apart)
HINT: Consider increasing the configuration parameter
"checkpoint_segments".
Clearly, this should only occur when specific checkpoint requests have
been made, shutdown checkpoints should not be included in the warning.
Best regards, Simon Riggs
Index: bgwriter.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/bgwriter.c,v
retrieving revision 1.3
diff -c -c -r1.3 bgwriter.c
*** bgwriter.c 3 Jun 2004 02:08:03 - 1.3
--- bgwriter.c 11 Jun 2004 11:51:37 -
***
*** 320,326
*/
if (do_checkpoint)
{
! if (CheckPointWarning != 0)
{
/*
* Ideally we should only warn if this checkpoint was
--- 320,326
*/
if (do_checkpoint)
{
! if (CheckPointWarning != 0 && checkpoint_requested)
{
/*
* Ideally we should only warn if this checkpoint was
---(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
[PATCHES] path.c char[strlen("xxx")] not portable
strlen inside variable declaration is not portable C (AIX):
char env_path[MAXPGPATH + strlen("PGLOCALEDIR=")];
use sizeof instead.
Please apply to current
Andreas
path.c.locale.patch
Description: path.c.locale.patch
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VisualC
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] pg_ctl using START with paths needing quotes
This is a really ugly hack (I take the blame since I gave Bruce the idea). There are a few things to note: . the .bat file should probably be created in the data dir - that's about the only place that we should be guaranteed we can write. . the command should be preceded by '@' to suppress echoing . the whole command, including redirections should go inside the .bat file, so that pg_ctl just issues 'start /b foo.bat' There are still things to clean up in pg_ctl, e.g. its handling of relative paths to the data dir. cheers andrew Bruce Momjian wrote: This applied patch changes the way pg_ctl starts on Win32. Using START, it is not possible to quote the executable name, who's directory might have spaces: START /B /program files/x.exe The fix is to create a temporary batch file in C:\ containing: /program files/x.exe and run START with the batch name: START /B C:\PG_CTL_323223.BAT then unlink the batch file. ---(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
