Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On Sat, Nov 10, 2007 at 03:17:13PM -0800, Trevor Talbot wrote: On 10/26/07, I wrote: On 10/26/07, Magnus Hagander [EMAIL PROTECTED] wrote: Can you try the attached patch? See how many backends you can get up to. This patch changes from using a single thread for each backend started to using the builtin threadpool functionality. It also replaces the pid/handle arrays with an i/o completion port. The net result is also, imho, much more readable code :-) The patch looks good; I'm not set up to build yet, but I should be able to test it sometime in the next week. Sorry about the long delay; I retested with the 8.3-beta2 installer, still Win2003 SP2 32bit. I stopped the test at 824 connections because I was about to run out of memory (1.25GB RAM + 3.75GB swap), but postmaster VM space usage was only 191MB. Great. I'm thinking this change may be big enough to actually backport to 8.2 - what to others feel about that? Assuming it is, I still think we should wait at least until we've run 8.3 RC for a while - probably until 8.3 has been actually released and run for a while, to make sure we have a *lot* of testing of it before we consider backpatching. As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? Dave, on your XP test, was that on a clean XP with nothing like AV or any 3rd party stuff on it? Available RAM seems like a pretty reasonable limit to me ;) Yeah, not much we can do about that one :-) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? Dave, on your XP test, was that on a clean XP with nothing like AV or any 3rd party stuff on it? No, it was on my XP laptop which runs Sophos AV. I'm not convinced it's AV related though - in my test code I proved pretty conclusively that just initialising user32.dll ate the desktop heap. /D ---(end of broadcast)--- TIP 1: 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: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On Mon, Nov 12, 2007 at 10:01:09AM +, Dave Page wrote: Magnus Hagander wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? Dave, on your XP test, was that on a clean XP with nothing like AV or any 3rd party stuff on it? No, it was on my XP laptop which runs Sophos AV. I'm not convinced it's AV related though - in my test code I proved pretty conclusively that just initialising user32.dll ate the desktop heap. I'm certainly not convinved about that either, but we should make a test on a VM at some point. Sophos AV has plugins into for example the explorer (I assume - most AV does, haven't used Sophos specifically myself), which may be done with extra DLLs loading along with user32.dll (runtime linked) or something like that. I just want to be sure we exclude that possibility. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander wrote: I'm certainly not convinved about that either, but we should make a test on a VM at some point. Sophos AV has plugins into for example the explorer (I assume - most AV does, haven't used Sophos specifically myself), which may be done with extra DLLs loading along with user32.dll (runtime linked) or something like that. I just want to be sure we exclude that possibility. Yeah, iirc it does. I don't have time for that at the moment, but I can fire you a copy of my test code if you do. /D ---(end of broadcast)--- TIP 1: 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: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sat, Nov 10, 2007 at 03:17:13PM -0800, Trevor Talbot wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? The XP SP2 machine I tried 8.2.5 on was chewing up about 3.1KB per process, and it's not running anything invasive (AV or otherwise). I've been trying to find out exactly what's in the desktop heap, but I haven't had much luck so far. Apparently Microsoft changed the implementation after Win2000, and didn't bother teaching the public debugging tools about it. The details just don't seem to exist anymore :( ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On Mon, Nov 12, 2007 at 04:00:04AM -0800, Trevor Talbot wrote: On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sat, Nov 10, 2007 at 03:17:13PM -0800, Trevor Talbot wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? The XP SP2 machine I tried 8.2.5 on was chewing up about 3.1KB per process, and it's not running anything invasive (AV or otherwise). Then I think we can claim that Server is just better than Workstation in this regard. Maybe we should put that in the FAQ? I've been trying to find out exactly what's in the desktop heap, but I haven't had much luck so far. Apparently Microsoft changed the implementation after Win2000, and didn't bother teaching the public debugging tools about it. The details just don't seem to exist anymore :( Yeah, there are very little docs at all about the desktop heap AFAICT. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 04:00:04AM -0800, Trevor Talbot wrote: On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sat, Nov 10, 2007 at 03:17:13PM -0800, Trevor Talbot wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? The XP SP2 machine I tried 8.2.5 on was chewing up about 3.1KB per process, and it's not running anything invasive (AV or otherwise). Then I think we can claim that Server is just better than Workstation in this regard. Maybe we should put that in the FAQ? I think it's safe to claim 2003 is better than XP, but I'm not sure that's enough to generalize into server vs workstation yet. It implies 2000 Server would be better than 2000 Pro, which might not be true. I'm also wondering whether 64bit XP behaves differently, since IIRC it's based on the 2003 kernel. Then there's Vista... Unfortunately I don't have access to any of these versions to test with at the moment. ---(end of broadcast)--- TIP 1: 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: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Trevor Talbot wrote: On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 04:00:04AM -0800, Trevor Talbot wrote: On 11/12/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sat, Nov 10, 2007 at 03:17:13PM -0800, Trevor Talbot wrote: As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. As Dave said, it could be that the server version uses a lot less heap per process, which would be another good reason to use server rather than XP to run postgresql. But might there also be other differences, such as some third party (or non-core microsoft) product installed? The XP SP2 machine I tried 8.2.5 on was chewing up about 3.1KB per process, and it's not running anything invasive (AV or otherwise). Then I think we can claim that Server is just better than Workstation in this regard. Maybe we should put that in the FAQ? I think it's safe to claim 2003 is better than XP, but I'm not sure that's enough to generalize into server vs workstation yet. It implies 2000 Server would be better than 2000 Pro, which might not be true. I'm also wondering whether 64bit XP behaves differently, since IIRC it's based on the 2003 kernel. Then there's Vista... Valid points, of course. Specifically, it'd be interesting to know where Vista stands, and possibly 2008 server. I don't care that much about 2000, really. I don't have installations of either one, though.. :-( //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
--- Original Message --- From: Trevor Talbot [EMAIL PROTECTED] To: Magnus Hagander [EMAIL PROTECTED] Sent: 10/11/07, 23:17:13 Subject: Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. That's interesting (and useful to know) - server is clearly not using nearly as much desktop heap when initialising user32 as XP. Available RAM seems like a pretty reasonable limit to me ;) Yup. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On 10/26/07, I wrote: On 10/26/07, Magnus Hagander [EMAIL PROTECTED] wrote: Can you try the attached patch? See how many backends you can get up to. This patch changes from using a single thread for each backend started to using the builtin threadpool functionality. It also replaces the pid/handle arrays with an i/o completion port. The net result is also, imho, much more readable code :-) The patch looks good; I'm not set up to build yet, but I should be able to test it sometime in the next week. Sorry about the long delay; I retested with the 8.3-beta2 installer, still Win2003 SP2 32bit. I stopped the test at 824 connections because I was about to run out of memory (1.25GB RAM + 3.75GB swap), but postmaster VM space usage was only 191MB. As for desktop heap, only 65KB of the service heap was allocated, or about 80 bytes per connection. No danger of hitting limits in the kernel memory pools either. Available RAM seems like a pretty reasonable limit to me ;) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On Mon, Oct 22, 2007 at 01:19:24PM -0700, Trevor Talbot wrote:
On 10/22/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Trevor Talbot wrote:
I'd probably take the approach of combining win32_waitpid() and
threads. You'd end up with 1 thread per 64 backends; when something
interesting happens the thread could push the info onto a queue, which
the new win32_waitpid() would check. Use APCs to add new backends to
threads with free slots.
I was planning to make it even easier and let Windows do the job for us,
just using RegisterWaitForSingleObject(). Does the same - one thread per
64 backends, but we don't have to deal with the queueing ourselves.
Oh, good call -- I keep forgetting the native thread pool exists.
Taking this one to -hackers once and for all now...
Can you try the attached patch? See how many backends you can get up to.
This patch changes from using a single thread for each backend started to
using the builtin threadpool functionality. It also replaces the pid/handle
arrays with an i/o completion port. The net result is also, imho, much more
readable code :-)
Beware - there's still plenty of debugging code in there :-)
//Magnus
Index: src/backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.542
diff -c -r1.542 postmaster.c
*** src/backend/postmaster/postmaster.c 26 Sep 2007 22:36:30 - 1.542
--- src/backend/postmaster/postmaster.c 26 Oct 2007 11:46:45 -
***
*** 331,344
#ifdef EXEC_BACKEND
#ifdef WIN32
- static void win32_AddChild(pid_t pid, HANDLE handle);
- static void win32_RemoveChild(pid_t pid);
static pid_t win32_waitpid(int *exitstatus);
! static DWORD WINAPI win32_sigchld_waiter(LPVOID param);
! static pid_t *win32_childPIDArray;
! static HANDLE *win32_childHNDArray;
! static unsigned long win32_numChildren = 0;
HANDLEPostmasterHandle;
#endif
--- 331,347
#ifdef EXEC_BACKEND
#ifdef WIN32
static pid_t win32_waitpid(int *exitstatus);
! static void WINAPI pgwin32_deadchild_callback(PVOID lpParameter, BOOLEAN
TimerOrWaitFired);
! static HANDLE win32ChildQueue;
!
! typedef struct
! {
! HANDLE waitHandle;
! HANDLE procHandle;
! DWORD procId;
! } win32_deadchild_waitinfo;
HANDLEPostmasterHandle;
#endif
***
*** 899,914
#ifdef WIN32
/*
!* Initialize the child pid/HANDLE arrays for signal handling.
*/
! win32_childPIDArray = (pid_t *)
! malloc(mul_size(NUM_BACKENDARRAY_ELEMS, sizeof(pid_t)));
! win32_childHNDArray = (HANDLE *)
! malloc(mul_size(NUM_BACKENDARRAY_ELEMS, sizeof(HANDLE)));
! if (!win32_childPIDArray || !win32_childHNDArray)
ereport(FATAL,
! (errcode(ERRCODE_OUT_OF_MEMORY),
!errmsg(out of memory)));
/*
* Set up a handle that child processes can use to check whether the
--- 902,913
#ifdef WIN32
/*
!* Initialize I/O completion port used to deliver list of dead children.
*/
! win32ChildQueue = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0,
1);
! if (win32ChildQueue == NULL)
ereport(FATAL,
! (errmsg(could not create I/O completion port for child
queue)));
/*
* Set up a handle that child processes can use to check whether the
***
*** 2072,2083
#define LOOPHEADER() (exitstatus = status.w_status)
#else /* WIN32 */
#define LOOPTEST()((pid = win32_waitpid(exitstatus)) 0)
! /*
!* We need to do this here, and not in CleanupBackend, since this is
!* to be called on all children when we are done with them. Could move
!* to LogChildExit, but that seems like asking for future trouble...
!*/
! #define LOOPHEADER() (win32_RemoveChild(pid))
#endif /* WIN32 */
#endif /* HAVE_WAITPID */
--- 2071,2077
#define LOOPHEADER() (exitstatus = status.w_status)
#else /* WIN32 */
#define LOOPTEST()((pid = win32_waitpid(exitstatus)) 0)
! #define LOOPHEADER()
#endif /* WIN32 */
#endif /* HAVE_WAITPID */
***
*** 3332,3343
int i;
int j;
charcmdLine[MAXPGPATH * 2];
- HANDLE childHandleCopy;
- HANDLE waiterThread;
HANDLE paramHandle;
BackendParameters *param;
SECURITY_ATTRIBUTES sa;
charparamHandleStr[32];
/* Make sure caller set up argv properly */
Assert(argc = 3);
--- 3326,3336
int i;
int j;
charcmdLine[MAXPGPATH * 2];
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On Fri, Oct 26, 2007 at 05:25:39AM -0700, Trevor Talbot wrote: On 10/26/07, Magnus Hagander [EMAIL PROTECTED] wrote: Can you try the attached patch? See how many backends you can get up to. This patch changes from using a single thread for each backend started to using the builtin threadpool functionality. It also replaces the pid/handle arrays with an i/o completion port. The net result is also, imho, much more readable code :-) The patch looks good; I'm not set up to build yet, but I should be able to test it sometime in the next week. I've uploaded a set of binary files to http://www.hagander.net/pgsql/pgsql_83_snapshot_win32child.zip. You'll need to get the dependency DLLs elsewhere, but you may have them already. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
On 10/26/07, Magnus Hagander [EMAIL PROTECTED] wrote: Can you try the attached patch? See how many backends you can get up to. This patch changes from using a single thread for each backend started to using the builtin threadpool functionality. It also replaces the pid/handle arrays with an i/o completion port. The net result is also, imho, much more readable code :-) The patch looks good; I'm not set up to build yet, but I should be able to test it sometime in the next week. ---(end of broadcast)--- TIP 1: 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: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Taking this one to -hackers once and for all now... Can you try the attached patch? See how many backends you can get up to. Regression tests run just fine, and I've run multiple pgbench runs with 3 and 4 sessions of 100 connections each*, with pgAdmin monitoring things at the same time. Saw up to 403 simultanteous connections in pg_stat_activity, and the system remained stable and responsive, albeit somewhat slower than normal. What was the memory space consumption of the postmaster process, and compared to without the patch? VM size in taskmgr should show that I think, and should show a much smaller footprint now.. /Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander wrote: Taking this one to -hackers once and for all now... Can you try the attached patch? See how many backends you can get up to. Regression tests run just fine, and I've run multiple pgbench runs with 3 and 4 sessions of 100 connections each*, with pgAdmin monitoring things at the same time. Saw up to 403 simultanteous connections in pg_stat_activity, and the system remained stable and responsive, albeit somewhat slower than normal. So, 400 connections on a 2.33GHz MacBook Pro running XP Pro with 2GB RAM - thats not too shabby :-) /D * For those that weren't peering over Magnus' or Greg's shoulder during various IM discussions over the last few days, I've found that the ~125 connection ceiling I was hitting when running from a command prompt was actually an as yet unsolved problem in pgbench, not the server. Multiple pgbench sessions seem to run just fine if kept to around 100 connections each. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander wrote: VM size in taskmgr should show that I think, and should show a much smaller footprint now.. With patch -4,492K Without patch: 28,224K Thats with 3 x 100 pgbench connections. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Dave Page wrote: Magnus Hagander wrote: VM size in taskmgr should show that I think, and should show a much smaller footprint now.. With patch -4,492K Without patch: 28,224K Thats with 3 x 100 pgbench connections. That's nice! But. That can't be address space usage, it has to be actual memory usage. Since each thread should chew up 4Mb of address space, and there's at least two threads in there :-) So looking at the VM column was obviously not correct. * looks up some docs* Right. You need to look at VM size in *process explorer*. VM size in task manager has nothing to do with VM size, it's the private bytes :-S And there is no way to see that info from task manager, I think. PE is your friend. Anyway. Other than a refresher on those, I'd be interested in two other important parts: * How many threads does it reach when you have 300 active backends? * Is there a handle leak? meaning once your 300 backends have exited, does the number of handles in the process drop down to the same value it had before? (sorry, wish I was in a position to run these tests myself, but I'm not right now) //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Dave Page wrote:
Magnus Hagander wrote:
Right. You need to look at VM size in *process explorer*. VM size in
task manager has nothing to do with VM size, it's the private bytes :-S
And there is no way to see that info from task manager, I think. PE is
your friend.
Anyway. Other than a refresher on those, I'd be interested in two other
important parts:
* How many threads does it reach when you have 300 active backends?
* Is there a handle leak? meaning once your 300 backends have exited,
does the number of handles in the process drop down to the same value it
had before?
Without patch:
VM: 1,322,792K
Idle threads: 6
Peak threads: 306
Handles at start: 576
Handles at end: 576
With patch:
VM: 98,088K
Idle threads: 3
Peak threads: 7
Handles at start: 576
Handles at end: 585 (585 again after second run).
Ah, now we're talking. That's the kind of reduction I was looking for :-)
I think the difference in handles is because the threadpool keeps some
things around. As long as it stays at 585 and comes back down after a
second run, we're fine at that - there's no leak.
Attached is an updated version of the patch, currently being tested by
both me and Dave. If it passes our tests, I'll apply this so it gets
included for broader testing in beta2.
//Magnus
Index: src/backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.542
diff -c -r1.542 postmaster.c
*** src/backend/postmaster/postmaster.c 26 Sep 2007 22:36:30 - 1.542
--- src/backend/postmaster/postmaster.c 26 Oct 2007 20:09:35 -
***
*** 331,344
#ifdef EXEC_BACKEND
#ifdef WIN32
- static void win32_AddChild(pid_t pid, HANDLE handle);
- static void win32_RemoveChild(pid_t pid);
static pid_t win32_waitpid(int *exitstatus);
! static DWORD WINAPI win32_sigchld_waiter(LPVOID param);
! static pid_t *win32_childPIDArray;
! static HANDLE *win32_childHNDArray;
! static unsigned long win32_numChildren = 0;
HANDLE PostmasterHandle;
#endif
--- 331,347
#ifdef EXEC_BACKEND
#ifdef WIN32
static pid_t win32_waitpid(int *exitstatus);
! static void WINAPI pgwin32_deadchild_callback(PVOID lpParameter, BOOLEAN TimerOrWaitFired);
! static HANDLE win32ChildQueue;
!
! typedef struct
! {
! HANDLE waitHandle;
! HANDLE procHandle;
! DWORD procId;
! } win32_deadchild_waitinfo;
HANDLE PostmasterHandle;
#endif
***
*** 899,914
#ifdef WIN32
/*
! * Initialize the child pid/HANDLE arrays for signal handling.
*/
! win32_childPIDArray = (pid_t *)
! malloc(mul_size(NUM_BACKENDARRAY_ELEMS, sizeof(pid_t)));
! win32_childHNDArray = (HANDLE *)
! malloc(mul_size(NUM_BACKENDARRAY_ELEMS, sizeof(HANDLE)));
! if (!win32_childPIDArray || !win32_childHNDArray)
ereport(FATAL,
! (errcode(ERRCODE_OUT_OF_MEMORY),
! errmsg(out of memory)));
/*
* Set up a handle that child processes can use to check whether the
--- 902,913
#ifdef WIN32
/*
! * Initialize I/O completion port used to deliver list of dead children.
*/
! win32ChildQueue = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 1);
! if (win32ChildQueue == NULL)
ereport(FATAL,
! (errmsg(could not create I/O completion port for child queue)));
/*
* Set up a handle that child processes can use to check whether the
***
*** 2072,2083
#define LOOPHEADER() (exitstatus = status.w_status)
#else /* WIN32 */
#define LOOPTEST() ((pid = win32_waitpid(exitstatus)) 0)
! /*
! * We need to do this here, and not in CleanupBackend, since this is
! * to be called on all children when we are done with them. Could move
! * to LogChildExit, but that seems like asking for future trouble...
! */
! #define LOOPHEADER() (win32_RemoveChild(pid))
#endif /* WIN32 */
#endif /* HAVE_WAITPID */
--- 2071,2077
#define LOOPHEADER() (exitstatus = status.w_status)
#else /* WIN32 */
#define LOOPTEST() ((pid = win32_waitpid(exitstatus)) 0)
! #define LOOPHEADER()
#endif /* WIN32 */
#endif /* HAVE_WAITPID */
***
*** 3332,3343
int i;
int j;
char cmdLine[MAXPGPATH * 2];
- HANDLE childHandleCopy;
- HANDLE waiterThread;
HANDLE paramHandle;
BackendParameters *param;
SECURITY_ATTRIBUTES sa;
char paramHandleStr[32];
/* Make sure caller set up argv properly */
Assert(argc = 3);
--- 3326,3336
int i;
int j;
char cmdLine[MAXPGPATH * 2];
HANDLE paramHandle;
BackendParameters *param;
SECURITY_ATTRIBUTES sa;
char paramHandleStr[32];
+ win32_deadchild_waitinfo *childinfo;
/* Make sure caller set up argv properly */
Assert(argc = 3);
***
*** 3345,3359
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander wrote: Right. You need to look at VM size in *process explorer*. VM size in task manager has nothing to do with VM size, it's the private bytes :-S And there is no way to see that info from task manager, I think. PE is your friend. Anyway. Other than a refresher on those, I'd be interested in two other important parts: * How many threads does it reach when you have 300 active backends? * Is there a handle leak? meaning once your 300 backends have exited, does the number of handles in the process drop down to the same value it had before? Without patch: VM: 1,322,792K Idle threads: 6 Peak threads: 306 Handles at start: 576 Handles at end: 576 With patch: VM: 98,088K Idle threads: 3 Peak threads: 7 Handles at start: 576 Handles at end: 585 (585 again after second run). /D ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Magnus Hagander [EMAIL PROTECTED] writes: Attached is an updated version of the patch, currently being tested by both me and Dave. If it passes our tests, I'll apply this so it gets included for broader testing in beta2. One question: what's this about? + #define _WIN32_WINNT 0x0500 This looks like it might be tightening our assumptions about which Windows flavors we can run on. I'm not necessarily against that, but it should be publicly discussed if it's happening. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2.3: Server crashes on Windows using Eclipse/Junit
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Attached is an updated version of the patch, currently being tested by both me and Dave. If it passes our tests, I'll apply this so it gets included for broader testing in beta2. One question: what's this about? + #define _WIN32_WINNT 0x0500 This looks like it might be tightening our assumptions about which Windows flavors we can run on. I'm not necessarily against that, but it should be publicly discussed if it's happening. It enables Windows 2000-specific headers. We already require Windows 2000 to run, so it doesn't restrict us anymore than we already are. It just exposes those parts of the header files. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
