Re: 8.2.3: Server crashes on Windows using Eclipse/Junit - Mailing list pgsql-general

From Trevor Talbot
Subject Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
Date
Msg-id 90bce5730710220804o4afb68d0wc7525a5227948e06@mail.gmail.com
Whole thread Raw
In response to Re: 8.2.3: Server crashes on Windows using Eclipse/Junit  (Dave Page <dpage@postgresql.org>)
Responses Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
List pgsql-general
On 10/22/07, Dave Page <dpage@postgresql.org> wrote:
> Dave Page wrote:
> > So, we seem to be hitting two limits here - the desktop heap, and
> > something else which is cluster-specific. Investigation continues...
>
> In further info, I've been testing this with the 8.3b1 release build
> that we put out with pgInstaller, and a build with all optional
> dependencies (OpenSSL, Kerberos, gettext, ldap etc) disabled. I'm seeing
> pretty much the same results with each - roughtly 9.6KB of desktop heap
> used per connection.

The question is where that's coming from.  I wondered if it was
desktop heap originally, but there's no reason it should be using it,
and that seems to be precisely the difference between my system and
the others.  Connections here are barely making a dent; at 490 there's
an entire 45KB committed in the service desktop.

> Magnus and I did observe that we're using 1 user object and 4 GDI
> objects per connection. If anyone happens to know how we might identify
> those, please shout as so far we've drawn a blank :-(

Those appear to belong to the console window.

I've yet to do anything that generates real load (lightweight system),
but a simple "select version()" doesn't make any difference here
either, and raising shared buffers just makes postmaster run out of VM
space faster.  (I don't think I mentioned that error before, but it
shows up as "FATAL:  could not create sigchld waiter thread: error
code 8".)

pgsql-general by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: looking for some real world performance numbers
Next
From: Richard Broersma Jr
Date:
Subject: Re: Select Command