[PATCHES] Two very minor win32 patches

2003-11-02 Thread Claudio Natoli
For src/backend/postmaster/postmaster.c and src/include/c.h (Note: should ioctlsocket_ret be initialized to 1 for BEOS too, and can it take an unsigned parameter? If so, could simplify.) --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041

[PATCHES] Win32 patch for Makefile.shlib

2003-11-02 Thread Claudio Natoli
If this is acceptable, I'll send a similar one for src/backend/Makefile Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email

Re: [PATCHES] Win32 patch for Makefile.shlib

2003-11-11 Thread Claudio Natoli
Of course, this only applied to head, no 7.4. Yes, that's correct. (strictly, at the time of creation, I was working off the WIN32_DEV branch...) --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] Bug in fd.c (FreeFile)

2003-11-25 Thread Claudio Natoli
I believe FreeFile has an off by one type error. Apart from possibly accessing past the end of the array, when combined with the while loop call from CleanupTempFiles, it contrives to fail to fclose a number of files [at a guess, floor((numAllocatedFiles-1)/2)] when CleanupTempFiles is called

Re: [PATCHES] Bug in fd.c (FreeFile)

2003-11-25 Thread Claudio Natoli
Nope. My bad. My head has an off by one error. Drop the first part of the patch, but the second part could be retained. Very minor. Off to hide in shame, Claudio -Original Message- From: Claudio Natoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 November 2003 12:34 PM To: [EMAIL

[PATCHES] Comments requested on attached fork/exec patch

2003-12-09 Thread Claudio Natoli
Hi all, here's a patch aimed at moving along the fork/exec development. It is not yet complete or ready for submission, but would like comments at this stage from the postgres developer community. The places of particular interest are denoted by FIXME: [fork/exec], however, some things I'd like

Re: [PATCHES] Comments requested on attached fork/exec patch

2003-12-09 Thread Claudio Natoli
Sorry all... I'll repost with a context diff when I get a chance. -Original Message- From: Claudio Natoli To: '[EMAIL PROTECTED]' Sent: 12/10/03 12:28 AM Subject: [PATCHES] Comments requested on attached fork/exec patch Hi all, here's a patch aimed at moving along the fork/exec

Re: [PATCHES] fork/exec patch

2003-12-14 Thread Claudio Natoli
Hi all, Dennis Bjorklund wrote: Also has to work on Unix too for testing. Everything can not work in unix, CreateProcess() and fork() are different. True (but CreateProcess and fork followed by exec are pretty close). I think what Bruce is implying is that, ideally, we'd like to keep

Re: [PATCHES] fork/exec patch

2003-12-16 Thread Claudio Natoli
[Thanks to Tom + Bruce] For the remaining comments... The number of FIXME or This is ugly comments doesn't ease my mind about this patch :-) How many of these issues do you plan to resolve? All of them, as we go along. Treat this as a first step. - break;

Re: [PATCHES] fork/exec patch

2003-12-16 Thread Claudio Natoli
Hi Neil, No. This isn't necessary (and what action would it take in any case?). It should write a log message. I'm not sure why this /shouldn't/ be done: if an operation fails, we should log that failure. This is standard practise. Fair enough. Will do (although, I'd point out that

Re: [PATCHES] fork/exec patch

2003-12-17 Thread Claudio Natoli
[Thought I replied to this already] I am now thinking we have to remove pgsql/data/pgsql_tmp unconditionally: [snip] The reason is that if they stop a postmaster that is fork/exec, install a non-exec postmaster, and restart, we should still clear out that directory. I guess what i am

[PATCHES] fork/exec patch: pgstat + BootstrapMain

2003-12-20 Thread Claudio Natoli
For application to HEAD, pending community review. Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the

[PATCHES] Proposed replacement for pipe under Win32

2003-12-23 Thread Claudio Natoli
To go in src/port/ directory. This is to allow the handles returned by pipe to be used in select() calls (which Win32 doesn't allow with the native pipe() call), thereby obviating the need for reworking of the select() mechanisms in pgstat.c. Additionally, something of the sort would be

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2003-12-26 Thread Claudio Natoli
Thanks for your comments Tom. Tom Lane writes: Claudio Natoli [EMAIL PROTECTED] writes: This has required some reworking of the existing code base, particularly to BackendFork (which now actually does the fork()). As such, I've been anticipating that this will be the most controversial

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2003-12-27 Thread Claudio Natoli
What I was suggesting with b) was to format up the command line for the items prefixed by * in the postmaster, do the fork (or fork/exec), and then run the authentication in, say PostgresMain. (Note: this is essentially what the fork/exec case currently does). Yeah, I noticed. If

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2003-12-28 Thread Claudio Natoli
[minor corrections (some duplication in arg passing); still under discussion/review] Cheers, Claudio -Original Message- From: Claudio Natoli [mailto:[EMAIL PROTECTED] Sent: Saturday, 27 December 2003 9:27 PM To: 'Tom Lane' Cc: '[EMAIL PROTECTED]' Subject: Re: [PATCHES] fork/exec

Re: [PATCHES] pg_usleep

2003-12-30 Thread Claudio Natoli
patch + new file attached. Haven't tested on Windows, but should be fine. Would be, except for a small typo (conditional operator has an additional : instead of a ?). Also, we might want to change to SleepEx, depending on how we eventually get signals implemented, but that's a story for

[PATCHES] fork/exec patch: CreateProcess calls for Win32

2004-01-08 Thread Claudio Natoli
For application to HEAD, pending community review. Drops in the CreateProcess calls for Win32 (essentially wrapping up the fork/exec portion of the port), and fixes a handful of whitespace issues (that no doubt I'm to blame for; my apologies) in the source base. Cheers, Claudio --- Certain

Re: [PATCHES] [pgsql-hackers-win32] Win32 signal code - first try

2004-01-08 Thread Claudio Natoli
Also, do we want this one #ifdef:ed in every place, or just #define it to nothing at all on non-windows platforms? I imagine the latter will be cleaner. Anyway. Comments on these points in particular, and in the whole thing in general? Workable path? I think it looks great. Well done!

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Whoever changed this: My fault. Thanks for the catch Jan. proc_exit(status); Should be proc_exit(0). My apologies, Claudio PS. I take it there is no regression test for this. Would this be a difficult one to knock up? --- Certain disclaimers and policies apply to all email sent

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Tom Lane wrote: I've just noticed another serious bit of breakage in CVS tip (though this might be fixed by Claudio's pending patch that reverts a lot of the code rearrangements). It's already been applied. Your push in the SubPostmaster direction was really useful; a lot cleaner, and fixed

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Tom Lane writes: Actually, on further reflection a separate array to store PIDs and cancel keys is probably a better idea. [snip] I still think it's unnecessary to make a separate shmem segment for it, though. Why is that? Don't we need the backends to have access to it to do a cancel

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
I think they are saying put the cancel key inside the existing shared memory segment. Ok. Thanks. I don't know when we actually attach to the main shared memory sigment in the child, but it would have to be sooner than when we need the cancel key. Yes. Currently, it happens too late.

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
I wrote: Just to be clear, this would involve turning the BackendList dlllist into an array in shared memory, right? If so, a couple of questions: Bruce Momjian wrote: I assumed a much simpler solution. I thought we would just have: struct { pid_t pid;

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Tom Lane: Per Jan's comment, there is no need to mess with the existing datastructure. I'd think more of *copying* the dllist into some array in shared memory. This is code that would only need to exist in the Windows port. (I thought Jan was referring to the PGPROC struct) This just

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Tom Lane wrote: I think the simplest way to make this work is to use an array that's 2*MaxBackend items long (corresponding to the max number of children the postmaster will fork). Actually, now that I think about it, is even that big enough. There is a reason BackendList is a list. In

Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization

2004-01-08 Thread Claudio Natoli
Tom Lane wrote: What it comes down to is I don't want the postmaster to be keeping its own state in shared memory --- that is, the array must be write-only memory as far as the postmaster is concerned. If we eliminate the Ok. Well, I can appreciate things from that point of view.

Win32 processCancelRequest/waitpid (was [PATCHES] fork/exec patch : pre-CreateProcess finalization)

2004-01-10 Thread Claudio Natoli
I wrote: But I'll happily concede the point, and prove it by knocking up a patch for it over the weekend (unless anyone else particularly wants to). Occurs to me I could kill 2 birds with one stone, and also implement another Win32 sticking point, namely the waitpid changes for the

[PATCHES] win32 patch: processCancelRequest/reaper (+ various minor changes )

2004-01-12 Thread Claudio Natoli
For application to HEAD, pending community review. Briefly, [all] Removed call to getppid in SendPostmasterSignal, replacing with a PostmasterPid variable, which gets set (early) in PostmasterMain - Q: Is this ok? Specifically, does anything call this function where getppid would not be the

Re: [PATCHES] win32 patch: processCancelRequest/reaper (+ various minor cha

2004-01-12 Thread Claudio Natoli
This time with a patch actually attached [doh!] -Original Message- From: Claudio Natoli Sent: Monday, 12 January 2004 6:45 PM To: '[EMAIL PROTECTED]' Subject: win32 patch: processCancelRequest/reaper (+ various minor changes) For application to HEAD, pending community

[PATCHES] win32 patch: allows source to be compiled + run under MingW

2004-01-28 Thread Claudio Natoli
For application to HEAD, pending community review (rand.c to go in src/port) Briefly, * configure + Makefile changes * shared memory attaching in EXEC_BACKEND case (+ minor fix for apparent cygwin bug under cygwin/EXEC_BACKEND case only) * PATH env var separator differences * missing win32

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SE

2004-02-01 Thread Claudio Natoli
Tom Lane wrote: If you want to allow the 3-parameter form to specify a negative step size, that's fine. But don't use a heuristic to guess the intended step direction. Have to agree. Ever used MatLab? They have a fairly intuitive approach: 1:5 = [1 2 3 4] 1:2:5 = [1 3 5] 5:1 = empty

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SE

2004-02-01 Thread Claudio Natoli
The one corner case not discussed is a step size of zero. Currently it returns zero rows, but I considered having it generate an ERROR. Following on from my previous comments, MatLab also returns an empty matrix in this condition. [Of course, whether or not this is the best behaviour (as

Re: [PATCHES] [pgsql-hackers-win32] Proposed dirmod.c fix for Win32

2004-02-02 Thread Claudio Natoli
not currently appear, afaics, to be included during a cygwin build. This patch does not address this deficiency. Cheers, Claudio -Original Message- From: Claudio Natoli [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 January 2004 8:11 PM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject

Re: [PATCHES] [HACKERS] Pre-1970 dates under Win32

2004-02-02 Thread Claudio Natoli
I'd not recommend spending a lot of time on patching the existing code. Erroring out rather than crashing is probably sufficient. Agreed. This fixes the ones bugging me now. I'll provide others as I trip over them. [Note: this'll mean some changes to the tests for Win32] Cheers, Claudio

Re: [PATCHES] [pgsql-hackers-win32] Proposed dirmod.c fix for Win

2004-02-02 Thread Claudio Natoli
I have fixed dirmod.c in CVS so it uses the same logic as crypt. Please review and tell me how you like it. Looks good. Thanks. Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

Re: [PATCHES] [pgsql-hackers-win32] New win32 signals patch (3)

2004-02-03 Thread Claudio Natoli
ATM, for review, not for applying. Comments: * Nice to see the fix for pqselect. Still want to object to the memcpy on the record :-) (though, as we've discussed, they'll work as things are now) * memcpy of an array of HANDLES will work seems to be taking advantage of knowledge of the

Re: [PATCHES] [pgsql-hackers-win32] win32 signals, part 4

2004-02-04 Thread Claudio Natoli
If there are no further comments from Claudio or anyone else, I feel this is now ready to be applied. Code walkthrough looks good. One final minor point to discuss: Is being unable to set a handler for things like CTRL_C_EVENT, CTRL_SHUTDOWN_EVENT etc really a non-fatal error? ISTM

Re: [PATCHES] win32 signals, part 4

2004-02-04 Thread Claudio Natoli
IIRC a separate babysitter thread just to handle message passing is exactly what Katie Ward did for UltraSQL ... the Win32 port done at NuSphere. Glad to see she was right about that. Or Katie and I are both wrong :-P Cheers, Claudio --- Certain disclaimers and policies apply to all

[PATCHES] win32 inode fix

2004-02-05 Thread Claudio Natoli
For community review and application to HEAD; minor patch. Under Win32, stat() returns an st_ino field, but it has no meaning (on Win2K, and possibly all Win32 variants, it is always 0). This causes a number of problems in the dfmgr.c logic, which basically all revolve around the fact that *any*

[PATCHES] CYGWIN correction; ipci rationalization

2004-02-05 Thread Claudio Natoli
For application to HEAD, following community review. * Changes incorrect CYGWIN defines to __CYGWIN__ * Some localtime returns NULL checks (when unchecked cause SEGVs under Win32 regression tests) * Rationalized CreateSharedMemoryAndSemaphores and AttachSharedMemoryAndSemaphores (Bruce, I

Re: [PATCHES] [pgsql-hackers-win32] win32 setitimer implementation

2004-02-17 Thread Claudio Natoli
Here is a patch that implements setitimer() on win32. With this patch applied, deadlock detection and statement_timeout now works. The file timer.c goes into src/backend/port/win32/. Minor comments: * timer.c has shmem.c in header * I'd suggest Asserts on the remaining 2 limitations

Re: [PATCHES] CYGWIN correction; ipci rationalization

2004-02-21 Thread Claudio Natoli
Any chance someone could take a peek at this before it bit-rots? Cheers, Claudio -Original Message- From: Claudio Natoli To: [EMAIL PROTECTED] Sent: 2/6/04 12:27 AM Subject: [PATCHES] CYGWIN correction; ipci rationalization For application to HEAD, following community review

[PATCHES] win32 int/float test fixes

2004-02-24 Thread Claudio Natoli
For application to HEAD, following community review. Corrects the int8/float4/float8 tests under win32. Cheers, Claudio P.S. Starting to back up on win32 related changes. If someone could look at the patch/es I've got waiting for application (and either apply 'em or let me know what fixes are

[PATCHES] dirmod (pg_usleep) bit-rot

2004-02-25 Thread Claudio Natoli
For immediate application to HEAD. Corrects bit-rot of recently applied patch. win32/cygwin only. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] Minor fixes (mostly win32)

2004-02-26 Thread Claudio Natoli
For application to HEAD, following community review. * Mostly, casting etc to remove compilation warnings in win32 only code. * main.c: set _IONBF to stdout/stderr under win32 (under win32, _IOLBF defaults to full buffering) * pg_resetxlog/Makefile: ensures dirmod.o gets cleaned (got bitten by

Re: [PATCHES] Minor fixes (mostly win32)

2004-02-26 Thread Claudio Natoli
These buffering fixes - are they enough to get around the buffering issues on the mingw console? I assume no? Nope. :-( That's one for the mingw/msys people. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers

[PATCHES] win32 regress makefile

2004-02-28 Thread Claudio Natoli
For application to CVS HEAD, following community review. (very minor) Adds the -W flag to the pwd call under Win32. This allows directories, which are munged by sed, such as: /e/cygwin/opt/diff9c/pgsql/src/test/regress/data/agg.data to be correctly passed as:

[PATCHES] canonicalize_path: initdb.c - port/path.c

2004-03-03 Thread Claudio Natoli
For application to HEAD. The win32 port backend will require the functionality provided by canonicalize_path. Patch moves it from initdb.c to port/path.c. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] pgstat EXEC_BACKEND

2004-03-08 Thread Claudio Natoli
For application to HEAD, following community review. Corrects a typo, introduces missing variables, and rearranges the initialization of stats process under EXEC_BACKEND. [A cleaner, rationalized approach to stat/backend/SSDataBase child processes under EXEC_BACKEND is on my TODO list. However

[PATCHES] win32 horology/float4/float8 fixes

2004-03-13 Thread Claudio Natoli
For application to HEAD. [float8-small-is-zero and float8-exp-three-digits will likely need similar changes] --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] pgstat win32 fix

2004-03-13 Thread Claudio Natoli
For application to HEAD, following community review. Check for EOF on pipe differs under win32, as it is based on a socket implementation. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] win32 open patch for held unlink

2004-03-15 Thread Claudio Natoli
For application to HEAD, following community review. [open.c destined for src/port] Win32 people: This has been kicked around on the thread for a bit, I've not been able to break it, but am still uncomfortable that it appears a novel solution. If you can see any reason why this approach should

Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink

2004-03-15 Thread Claudio Natoli
Claudio, how does this handle renames if the file is open by someone else? Does this remove the need to loop over the rename? To be honest, I don't know that it does. [Will report back later.] Two points though: a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware.

Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink

2004-03-15 Thread Claudio Natoli
a) This could doesn't alleviate the needs for dirmod.c, as This CODE doesn't alleviate the NEED for... Sheesh, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink

2004-03-15 Thread Claudio Natoli
Agreed, we still need dirmod.c in case someone has opened it using a non-unix mode. Ok. Wanted to make sure I was on the same page. My only question was whether this new mode makes rename possible on a target file opened by another backend. Looks good. Wrote a pair of 2 liner driver

Re: [PATCHES] Removal of win32-specific rename code

2004-03-15 Thread Claudio Natoli
main file. WIth Claudio's fix, this isn't necessary. Bruce, are you sure this is true? The fix is only for files than are open()'d, not fopen()'d (as per AllocateFile). Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these

Re: [PATCHES] Removal of win32-specific rename code

2004-03-16 Thread Claudio Natoli
If your fix works, I will change the Win32-specific code to use open() and fdopen(). The only advantage to the old code was that it would release locks, then go into a rename loop, which is horid, and we need to avoid the loop. Ah, I see. Should've been obvious you had that in mind

Re: [PATCHES] Patch for select and APC on win32

2004-03-22 Thread Claudio Natoli
Here's a patch implementing the thread method to workaround the bug with socket calls in signal handlers. See details in mail to pgsql-hackers-win32 a couple of minutes ago. Looks ok, but wouldn't it be better placed in pgstat.c? My $0.02, Claudio --- Certain disclaimers and policies

Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink

2004-03-23 Thread Claudio Natoli
Revised patch, for application to HEAD [open.c destined for src/port] --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em

Re: [PATCHES] Patch for select and APC on win32

2004-03-23 Thread Claudio Natoli
What I am wondering about now, is where else we need to change? AFAICS, there is (at least?) one signal handler that performs sockets ops, namely Async_NotifyHandler. Actually, I don't think we need to do anything about that one. This signal handler is used in the backend (not

[PATCHES] installdir patch for win32

2004-03-24 Thread Claudio Natoli
For application to HEAD, following community review. Supplement to previous win32 patch for dfmgr. Win32 replacement for configure time constants like PKGLIBDIR. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies

[PATCHES] APC/socket fix (final?)

2004-03-24 Thread Claudio Natoli
For application to HEAD. This should take care of most, if not all, cases where a backend can be interrupted in a blocking socket operation by a signal which itself performs a socket operation (which interacts badly with our APC-based signal implementation). --- Certain disclaimers and

Re: [PATCHES] APC/socket fix (final?)

2004-03-25 Thread Claudio Natoli
Would look more consistent if the code looked like if (n 0 errno == ERROR_IO_PENDING) errno = EINTR; It would be more consistent, but unfortunately GetLastError() != errno. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full

Re: [PATCHES] installdir patch for win32

2004-03-25 Thread Claudio Natoli
Tom Lane wrote: If the problem is that we need PKGLIBDIR not to be frozen at compile time, then let's fix the problem for everybody, not add a pile of undocumented #ifdef WIN32 hacks. (And it is a problem for everybody; Happy to go with whatever you can suggest. However, will point out that

Re: [PATCHES] APC/socket fix (final?)

2004-03-25 Thread Claudio Natoli
Ugh. Is there a way we can insert a wrapper layer without modifying the call sites? I'm thinking of some kind of macro hack, say [snip] Sure. Think we've even done this before (also, prevents developers needing to remember to use pg_*). The reason I think it was avoided for select(), in

Re: [PATCHES] installdir patch for win32

2004-03-25 Thread Claudio Natoli
I'm not expecting to see zero ifdefs --- certainly not in the port modules ;-). But Bruce's search, further up in the thread, showed that #ifdef WIN32's are sneaking into a lot of modules that probably shouldn't have any platform dependencies. For the most part, I disagree (in fact, I was

Re: [PATCHES] APC/socket fix (final?)

2004-03-26 Thread Claudio Natoli
Hi all, Magnus Hagander wrote: The third option is to redefine all these functions into our own, and implement our own emulation layer. This means our own select(), send(), recv() (more? I don't think so). And have these call the native winsock APIs (WSAEventSelect(), WSASend(), WSARecv()

Re: [PATCHES] APC/socket fix (final?)

2004-03-26 Thread Claudio Natoli
Your patch has been added to the PostgreSQL unapplied patches list at: Bruce, please cancel the original patch. The attached patch is for (possible) application to HEAD, following meritocratic contest [socket.c for src/port] Been iterating with Magnus extensively off-list, and he is well on

[PATCHES] MSFT compiler fixes + misc

2004-03-31 Thread Claudio Natoli
For application to HEAD, following community review. Corrects issues recently posted by Dann Corbit, allowing libpq/psql to be built under VC++. Moves a pgstat win32 #def to port.h --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these

[PATCHES] win32 fixes

2004-04-13 Thread Claudio Natoli
For application to HEAD, following community review. * Most changes are to fix warnings issued when compiling win32 * removed a few redundant defines * get_user_name safe under win32 * rationalized pipe read EINTR for win32 * changed all backend instances of sleep() to pg_usleep - except for

Re: [PATCHES] win32 fixes

2004-04-13 Thread Claudio Natoli
* rationalized pipe read EINTR for win32 Should read: * rationalized pipe read EOF for win32 Corrected patch attached. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

Re: [PATCHES] FW: Timezone library

2004-04-30 Thread Claudio Natoli
Bruce Momjian writes: I am confused why you are linking the timezone library into pg_dump and pg_controldata. Is that required? At the time, cvs HEAD required it; perhaps I caught you mid-commit. I thought it was a fast moving target to try to hit. :-) All looks good now. Cheers, Claudio

[PATCHES] mingw regression test fixes

2004-04-30 Thread Claudio Natoli
For application to HEAD. As Andrew Dunstan appears to have cracked the regression test buffering nut, this patch makes sure that: * correct platform specific regression files are used under ming * pwd prints out a usable win32 pathname Cheers, Claudio --- Certain disclaimers and policies

Re: [PATCHES] win32: whitespace in dir names, shmem bug

2004-05-03 Thread Claudio Natoli
Great to see you caught that. That's one more off my list of things to dig into. Are there any not listed here: http://momjian.postgresql.org/main/writings/pgsql/win32.html If so, they probably should be put up. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent

[PATCHES] win32 service proposal

2004-05-03 Thread Claudio Natoli
[For review only. Not for committing.] Decided to take a crack at this in the interests of knocking over the remaining TODO win32 items asap. Would appreciate any comments on the code, particularly from win32 people. An obvious missing feature is allowing the service to be registered under a

[PATCHES] win32 substitute_libpath_macro changes

2004-06-10 Thread Claudio Natoli
For application to HEAD, following community review. Determines the PKGLIBDIR equivalent under win32. Requires pgsql lib and bin directories to be packaged under the same root directory (eg. some path/pgsql/bin and some path/pgsql/lib) for the win32 port, which does not appear to be an onerous

Re: [PATCHES] stderr win32 admin check

2004-06-15 Thread Claudio Natoli
At least I don't htink it's in what Claudio has so far - Claudio? Lots of work to get into your framework? The original patch I submitted actually *required* a service name, allowing any number of postgres installations. I have no intention of removing that. Cheers, Claudio --- Certain

[PATCHES] pg_ctl service integration for WIN32

2004-06-16 Thread Claudio Natoli
Here's a rough first cut, close to application state but not a finished work. Might be pushed for time over the next week, so if there are major criticisms it might need someone else to pick this up in the short term. I'll happily redo any minor bits. Comments? Cheers, Claudio --- Certain

Re: [PATCHES] pg_ctl service integration for WIN32

2004-06-16 Thread Claudio Natoli
Bruce Momjian writes: Wow, my START /B code stays in pg_ctl? Interesting. I thought that was going to be ripped out. Didn't touch on anything other than service integration. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of

Re: [PATCHES] pg_ctl service integration for WIN32

2004-06-16 Thread Claudio Natoli
Dave Page writes: Looks OK to me at a quick glance. One thought though, whilst I like the idea of using service pause to do a SIGHUP from a convenience point of view, it's not exactly the expected behaviour and might leave the inexperienced user wondering why the server is still running

Re: [PATCHES] [PATCH] s_lock support for win32

2004-07-01 Thread Claudio Natoli
The win32 port doesn't have a native user space spinlock implementation yet. It does when compiled with MingW. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

Re: [PATCHES] [PATCH] s_lock support for win32

2004-07-01 Thread Claudio Natoli
Tom Lane writes: Claudio Natoli [EMAIL PROTECTED] writes: The win32 port doesn't have a native user space spinlock implementation yet. It does when compiled with MingW. Are we intending to support any other compilers/build environments than that one? Not currently; at least

[PATCHES] [pgsql-hackers-win32] pg_ctl --help

2004-07-15 Thread Claudio Natoli
pg_ctl --help ---skiped--- -P user name of account to register PostgreSQL server -U password of account to register PostgreSQL server ---skiped--- I think that isn't right ;) Good thinking... :-) Patch attached (but probably easier for any committer to make the change

Re: [PATCHES] Pipe fixes for win32 services

2004-07-24 Thread Claudio Natoli
Tom Lane writes: I can't speak to the details of the Windows process-launch code, FWIW, it checks out fine to me. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

[PATCHES] Win32 bug fix

2004-08-25 Thread Claudio Natoli
Could someone please eyeball the attached patch for errors and as a correction for: http://archives.postgresql.org/pgsql-bugs/2004-08/msg00307.php Also, could someone (Maksim?) please reproduce the bug on their system, and then confirm that the patch corrects (as I seem unable to reproduce the

Re: [PATCHES] [pgsql-hackers-win32] [BUGS] Win32 deadlock detection not wor

2004-09-02 Thread Claudio Natoli
Just outta curiosity, why wasn't that detected by the regression tests? There is a test that depends on statement_timeout working ... For the record, this was reported here a couple days after the plpgsql test was changed: http://archives.postgresql.org/pgsql-hackers/2004-08/msg00482.php

Re: [PATCHES] [pgsql-hackers-win32] [BUGS] Win32 deadlock detecti

2004-09-03 Thread Claudio Natoli
Magnus Hagander writes: Here's a more complete patch that addresses all the places where WaitForxxx can block. The previous fix only fixed statement_timeout, not the deadlock situation. I can confirm that the patch corrects the stated issues. Cheers, Claudio --- Certain disclaimers and

Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32

2004-09-08 Thread Claudio Natoli
Win32 compile fixes for pgbench, pgcrypto, and tsearch. Note: pgbench is the only one I actually use, and hence have tested Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a

Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32

2004-09-08 Thread Claudio Natoli
Win32 compile fix for misc_utils. Note: As before, un-tested. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a

Re: [PATCHES] Bad bug in fopen() wrapper code

2006-09-24 Thread Claudio Natoli
Hello guys, it's been a while, but... What's bugging me is that 0 and O_EXCL give the same answer, and O_TRUNC and O_TRUNC | O_EXCL give the same answer, This is ok, as (iirc) O_EXCL only has effect in the presence of O_CREAT. (a comment to this effect would help here, as well as perhaps

Re: [PATCHES] Bad bug in fopen() wrapper code

2006-09-27 Thread Claudio Natoli
Magnus Hagander writes: Now, I still twist my head around the lines: if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0 || (fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags (O_TEXT | O_BINARY)) 0))) With the _setmode() call deep in the if