Laurent Duperval wrote:
Does this allow creating more connections? At some point, the discussion
became too technical for me, and I no longer could tell if the answer was
for developers of for users.
Yeah, it did become something of an investigation into the problem which
probably should have
On 11/29/07, Laurent Duperval <[EMAIL PROTECTED]> wrote:
> To summarize: when I run unit tests with eclipse (and with Ant) on
> Windows, at some point, I run out of available connections. I tried
> increasing the maximum number of connections, but then I started seeing
> the postgres server die an
Hi,
I'm not sure if this is good netiquette, or not. I'm reviving a month-old
thread, because I'm trying to figure out how to resolve the issue.
To summarize: when I run unit tests with eclipse (and with Ant) on
Windows, at some point, I run out of available connections. I tried
increasing the ma
"Dave Page" wrote:
>> --- Original Message ---
>> From: Rainer Bauer <[EMAIL PROTECTED]>
>> To: pgsql-general@postgresql.org
>> Sent: 26/10/07, 18:09:26
>> Subject: Re: [GENERAL] 8.2.3: Server crashes on Windows using Eclipse/Junit
>>
> --- Original Message ---
> From: Rainer Bauer <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 26/10/07, 18:09:26
> Subject: Re: [GENERAL] 8.2.3: Server crashes on Windows using Eclipse/Junit
>
> Dave could you add that it's the third
Dave Page wrote:
>Magnus Hagander wrote:
>> Rainer Bauer wrote:
>>> After increasing the session heap size in the registry from 512KB to 1024KB
>>> the no. of connections was roughly doubled. So this might be a solution for
>>> people running out of Desktop heap.
>>>
>>> Alter the value of the fol
Magnus Hagander wrote:
> Rainer Bauer wrote:
>> After increasing the session heap size in the registry from 512KB to 1024KB
>> the no. of connections was roughly doubled. So this might be a solution for
>> people running out of Desktop heap.
>>
>> Alter the value of the following key
>>
>>
>> The
Rainer Bauer wrote:
> After increasing the session heap size in the registry from 512KB to 1024KB
> the no. of connections was roughly doubled. So this might be a solution for
> people running out of Desktop heap.
>
> Alter the value of the following key
>
>
> The numeric values following "Share
On 10/23/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> "Trevor Talbot" wrote:
> >It could be that there's a significant difference between XP and 2003
> >in how that's handled though. I do have an XP SP2 machine here with
> >512MB RAM, and I'll try tests on it as soon as I can free up what it's
>
On 10/23/07, Harald Armin Massa <[EMAIL PROTECTED]> wrote:
> > The Desktop Heap appears to be a place for processes belonging to the same
> > "desktop" to allocate shared objects such as GUI elements. These are
> > allocated
> > in shared space so they can be manipulated by any process running in
Harald Armin Massa wrote:
> Replying to myself
>> Postgres is definitely NOT started as LocalSystem account; so using a
>> "logical not" on Microsofts Words that could indicate the reason why
>> our service-backends consume that memory? Add to this that MS SQL runs
>> as LocalSystem; and as muc
Replying to myself
> Postgres is definitely NOT started as LocalSystem account; so using a
> "logical not" on Microsofts Words that could indicate the reason why
> our service-backends consume that memory? Add to this that MS SQL runs
> as LocalSystem; and as much as I know also Oracle.
just s
> > why does every backend need its own heap for user32.dll or
> > shell32.dll? Wasn't the point of shared dlls to be shared?
>
> The Desktop Heap appears to be a place for processes belonging to the same
> "desktop" to allocate shared objects such as GUI elements. These are allocated
> in shared s
Harald Armin Massa wrote:
> Dave,
>
>> It's coming from direct dependencies on user32.dll (from which we use
>> wsprintf()) and shell32.dll (from which we use SHGetSpecialFolderPath())
>> and is allocated when ResumeThread() is called to kickstart the new
>> backend,
>
> why does every backend ne
"Harald Armin Massa" <[EMAIL PROTECTED]> writes:
> Dave,
>
>> It's coming from direct dependencies on user32.dll (from which we use
>> wsprintf()) and shell32.dll (from which we use SHGetSpecialFolderPath())
>> and is allocated when ResumeThread() is called to kickstart the new
>> backend,
>
> wh
Dave,
> It's coming from direct dependencies on user32.dll (from which we use
> wsprintf()) and shell32.dll (from which we use SHGetSpecialFolderPath())
> and is allocated when ResumeThread() is called to kickstart the new
> backend,
why does every backend need its own heap for user32.dll or
shel
Rainer Bauer wrote:
>> ...yep, under XP I'm using about 3.1KB of the service heap per
>> connection, which tears through it quite a bit faster. Now to figure
>> out exactly where it's coming from...
>
> I can confirm this here (WinXP SP2).
It's coming from direct dependencies on user32.dll (from
"Trevor Talbot" wrote:
>I wrote:
>
>[ desktop heap usage ]
>
>> It could be that there's a significant difference between XP and 2003
>> in how that's handled though. I do have an XP SP2 machine here with
>> 512MB RAM, and I'll try tests on it as soon as I can free up what it's
>> currently occup
Magnus Hagander <[EMAIL PROTECTED]> writes:
> We're not talking about the backends, we're talking about the backend
> waiter threads whose sole purpose is to wait for a backend to die and
> then raise a signal when it does.
Oh, OK, I had not twigged to exactly what the threads were being used
for.
On 10/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > 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 th
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> 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.
>> Should be r
Magnus Hagander <[EMAIL PROTECTED]> writes:
> 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.
> Should be rather trivial to do.
Magnus Hagander wrote:
> Yeah, it could be that the newer MSVCRT files do something we don't
> like.. Other than that, did we upgrade to a different version of some of
> our dependents?
Most of them - but my test build is without any of them:
our $config = {
asserts=>1, # --en
Dave Page wrote:
> So the only other changes I can think of that might affect things are
> the VC++ build or the shared memory changes, though I can't see why they
> would cause problems offhand. I'll go try a mingw build...
mingw build of stock 8.3b1, no configure options specified at all,
consum
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
> >
Dave Page wrote:
> Magnus Hagander wrote:
>> Could you try a build without SSPI? It should be as simple as removing
>> the #define ENABLE_SSPI 1 from port/win32.h. I don't think you need to
>> touch the linker lines at all, actually, so try without first.
>
> Nope, doesn't help - still using aroun
Magnus Hagander wrote:
> Could you try a build without SSPI? It should be as simple as removing
> the #define ENABLE_SSPI 1 from port/win32.h. I don't think you need to
> touch the linker lines at all, actually, so try without first.
Nope, doesn't help - still using around 9.7KB per connection. Ju
Trevor Talbot wrote:
> On 10/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>>> I tried generating idle connections in an effort to reproduce
>>> Laurent's problem, but I ran into a local limit instead: for each
>>> backend, postmaster creates a thread and burns 4MB of its 2GB address
>>> spa
* Magnus Hagander:
> Oh, that's interesting. That's actually a sideeffect of us increasing
> the stack size for the postgres.exe executable in order to work on other
> things. By default, it burns 1MB/thread, but ours will do 4MB. Never
> really thought of the problem that it'll run out of address
Florian Weimer wrote:
> * Magnus Hagander:
>
>> Oh, that's interesting. That's actually a sideeffect of us increasing
>> the stack size for the postgres.exe executable in order to work on other
>> things. By default, it burns 1MB/thread, but ours will do 4MB. Never
>> really thought of the problem
Dave Page wrote:
> Trevor Talbot wrote:
>> 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 maki
Trevor Talbot wrote:
> I wrote:
>
> [ desktop heap usage ]
>
>> It could be that there's a significant difference between XP and 2003
>> in how that's handled though. I do have an XP SP2 machine here with
>> 512MB RAM, and I'll try tests on it as soon as I can free up what it's
>> currently occu
I wrote:
[ desktop heap usage ]
> It could be that there's a significant difference between XP and 2003
> in how that's handled though. I do have an XP SP2 machine here with
> 512MB RAM, and I'll try tests on it as soon as I can free up what it's
> currently occupied with.
...yep, under XP I'm
Trevor Talbot wrote:
> 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
On 10/22/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> I read somewhere that Vista makes the size of the desktop heap dynamic, but
> you were on 2003, right?
Yeah, 32bit 2003 SP2, which has the same limits as XP. It looks like
Vista also has the same limits on actual heap sizes, but manages
k
On Mon, Oct 22, 2007 at 08:04:03AM -0700, Trevor Talbot wrote:
> On 10/22/07, Dave Page <[EMAIL PROTECTED]> 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 furth
On 10/22/07, Dave Page <[EMAIL PROTECTED]> 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
On 10/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > I tried generating idle connections in an effort to reproduce
> > Laurent's problem, but I ran into a local limit instead: for each
> > backend, postmaster creates a thread and burns 4MB of its 2GB address
> > space. It fails around 490.
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
dependenc
On Mon, Oct 22, 2007 at 04:03:35PM +0200, Rainer Bauer wrote:
> >> shared_buffers = 512MB
> >
> >As a general note, thsi is *way* too high. All evidence I've seen points to
> >that you should have shared_buffers as *small* as possible on win32,
> >because memory access there is slow. And leave more
On 10/22/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> Well after installing Postgres explorer and starting the system information
> program the kernel memory section shows me the current count, but not the
> limits (it says "no symbols"). I am currently downloading the "Debugging Tools
> for Wind
Dave Page wrote:
>So, we seem to be hitting two limits here - the desktop heap, and
>something else which is cluster-specific. Investigation continues...
I will make these tests tonight or tomorrow morning and will let you know.
Rainer
---(end of broadcast)--
Magnus Hagander schrieb:
>On Sun, Oct 21, 2007 at 09:43:27PM +0200, Rainer Bauer wrote:
>> Magnus Hagander wrote:
>>
>> >Trevor Talbot wrote:
>> >> On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> Anyway, the problem are the no. of semaphores created by Postgres:
>> >>> Every ba
Magnus Hagander wrote:
> Another followup. Been working with Dave on and off today (well, him mostly
> on to be honest, me a bit more on and off), and it seems that both our
> repros clearly blame the desktop heap, and nothing else. Please use the
> desktop heap tool and see if it breaks when the d
On Mon, Oct 22, 2007 at 10:41:14AM +0200, Magnus Hagander wrote:
> On Mon, Oct 22, 2007 at 10:23:16AM +0200, Magnus Hagander wrote:
> > > >> I tried going up to 2 max_connections, and still blew postmaster's
> > > >> VM space long before paged pool was exhausted. I couldn't test any
> > > >> h
On Mon, Oct 22, 2007 at 10:23:16AM +0200, Magnus Hagander wrote:
> > >> I tried going up to 2 max_connections, and still blew postmaster's
> > >> VM space long before paged pool was exhausted. I couldn't test any
> > >> higher values, as there's some interaction between max_connections and
> >
On Sun, Oct 21, 2007 at 09:43:27PM +0200, Rainer Bauer wrote:
> Magnus Hagander wrote:
>
> >Trevor Talbot wrote:
> >> On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> >>
> >>> Anyway, the problem are the no. of semaphores created by Postgres:
> >>> Every backend creates at least 4* semaphor
Magnus Hagander wrote:
>Trevor Talbot wrote:
>> On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
>>
>>> Anyway, the problem are the no. of semaphores created by Postgres:
>>> Every backend creates at least 4* semaphores. Just
>>> increase to an unusual high value (say 1) and
>>> start cr
Trevor Talbot wrote:
> On 10/17/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> On Wed, Oct 17, 2007 at 02:40:14AM -0400, Tom Lane wrote:
>
>>> Maybe we should put an #ifdef WIN32 into guc.c to limit max_connections
>>> to something we know the platform can stand? It'd be more comfortable
>>> i
Trevor Talbot wrote:
> On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
>
>> Anyway, the problem are the no. of semaphores created by Postgres:
>> Every backend creates at least 4* semaphores. Just
>> increase to an unusual high value (say 1) and
>> start creating new connections while mo
On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> Anyway, the problem are the no. of semaphores created by Postgres:
> Every backend creates at least 4* semaphores. Just
> increase to an unusual high value (say 1) and
> start creating new connections while monitoring the handle count.
H
Hello Trevor,
Sunday, October 21, 2007, 12:15:25 AM, you wrote:
TT> On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
>> I could reproduce this here:
>>
>> Server closed the connection unexpectedly
>> This probaly means the server terminated abnormally before or while
>> processing
>> the re
I wrote
> Anyway, the problem are the no. of semaphores created by Postgres:
> Every backend creates at least 4* semaphores.
Sorry, this must read semaphores, not 4 times.
Rainer
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
--- Rainer Bauer <[EMAIL PROTECTED]> wrote:
> I could reproduce this here:
>
> Server closed the connection unexpectedly
> This probaly means the server terminated abnormally before or while
> processing
> the request
>
> 2007-10-20 23:33:42 LOG: server process (PID 5240) exited with exit
> cod
On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> I could reproduce this here:
>
> Server closed the connection unexpectedly
> This probaly means the server terminated abnormally before or while processing
> the request
>
> 2007-10-20 23:33:42 LOG: server process (PID 5240) exited with exit
Shelby Cain wrote:
>--- Trevor Talbot <[EMAIL PROTECTED]> wrote:
>
>> On 10/20/07, Shelby Cain <[EMAIL PROTECTED]> wrote:
>>
>> > I'd personally vote for a lower warning limit like 175 as I can
>> > consistently crash Postgresql on Windows system right around the
>> 200th
>> > connection.
>>
>>
On 10/20/07, Shelby Cain <[EMAIL PROTECTED]> wrote:
>
> --- Trevor Talbot <[EMAIL PROTECTED]> wrote:
>
> > On 10/20/07, Shelby Cain <[EMAIL PROTECTED]> wrote:
> >
> > > I'd personally vote for a lower warning limit like 175 as I can
> > > consistently crash Postgresql on Windows system right around
I wrote:
>You are right. I just did a quick test and depending on the handle type these
>limits are quite high. I could create 5 millions events or 4 millions
>semaphores or 3,5 millions mutexes before the system returned error 1816
>ERROR_NOT_ENOUGH_QUOTA "Not enough quota is available to process
--- Trevor Talbot <[EMAIL PROTECTED]> wrote:
> On 10/20/07, Shelby Cain <[EMAIL PROTECTED]> wrote:
>
> > I'd personally vote for a lower warning limit like 175 as I can
> > consistently crash Postgresql on Windows system right around the
> 200th
> > connection.
>
> What error gets logged for yo
"Trevor Talbot" wrote:
>On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
>> "Magnus Hagander" wrote:
>>
>> >> - Max_connections is set to 500. I did that originally because I kept
>> >> seeing a message about no connection available and I thought it was
>> >> because I was not allocating enoug
On 10/20/07, Shelby Cain <[EMAIL PROTECTED]> wrote:
> I'd personally vote for a lower warning limit like 175 as I can
> consistently crash Postgresql on Windows system right around the 200th
> connection.
What error gets logged for your crashes?
---(end of broadcast)-
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> How about we just emit a warning..
>
> WARNING: Connections above 250 on Windows platforms may have
> unpredictable results.
>
> Joshua D. Drake
>
I'd personally vote for a lower warning limit like 175 as I can
consistently crash Postgresql
On 10/20/07, Rainer Bauer <[EMAIL PROTECTED]> wrote:
> "Magnus Hagander" wrote:
>
> >> - Max_connections is set to 500. I did that originally because I kept
> >> seeing a message about no connection available and I thought it was
> >> because I was not allocating enough connections. My machine has
On 10/17/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 17, 2007 at 02:40:14AM -0400, Tom Lane wrote:
> > Maybe we should put an #ifdef WIN32 into guc.c to limit max_connections
> > to something we know the platform can stand? It'd be more comfortable
> > if we understood exactly wh
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> How about we just emit a warning..
>>>
>>> WARNING: Connections above 250 on Windows platforms may have
>>> unpredictable results.
>
>> That's probably a better idea. I'll go look at that unless people feel we
>> should just sti
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> How about we just emit a warning..
>>
>> WARNING: Connections above 250 on Windows platforms may have
>> unpredictable results.
> That's probably a better idea. I'll go look at that unless people feel we
> should just stick it in docd/faq?
Unles
> > > Maybe we should put an #ifdef WIN32 into guc.c to limit
> > > max_connections to something we know the platform can stand? It'd
> > > be more comfortable if we understood exactly where the limit was,
> > > but I think I'd rather have an "I'm sorry Dave, I can't do that"
> > > than random-see
"Magnus Hagander" wrote:
>> - Max_connections is set to 500. I did that originally because I kept
>> seeing a message about no connection available and I thought it was
>> because I was not allocating enough connections. My machine has 2GB of RAM.
>
>There's your problem. 500 is way above what the
On Wed, 17 Oct 2007 09:22:11 +0200
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Maybe we should put an #ifdef WIN32 into guc.c to limit
> > max_connections to something we know the platform can stand? It'd
> > be more comfortable if we understood exactly where the limit was,
> > but I think I'd
On Wed, Oct 17, 2007 at 02:40:14AM -0400, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >> - Max_connections is set to 500.
>
> > There's your problem. 500 is way above what the windows version can
> > handle. IIRC the hard max is somewhere around 200 depending on some OS
> > f
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> - Max_connections is set to 500.
> There's your problem. 500 is way above what the windows version can
> handle. IIRC the hard max is somewhere around 200 depending on some OS
> factors that we don't entirely know.
Maybe we should put an #ifdef WIN
> Hi,
>
> Sorry for top-posting but since I am answering questions that don't all
> appear in this message:
>
> - I installed the default download of Postgres. I didn't compile myself,
> so it's probably the mingw version
It is.
> - Max_connections is set to 500. I did that originally because
Hi,
Sorry for top-posting but since I am answering questions that don't all
appear in this message:
- I installed the default download of Postgres. I didn't compile myself,
so it's probably the mingw version
- Max_connections is set to 500. I did that originally because I kept
seeing a message a
On 10/16/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Laurent Duperval wrote:
> > >> I get en error in the logs that state:
> > >>
> > >> Server process exited with exit code -1073741502
FYI, this exit code means a DLL's initialization routine indicated
failure during process startup.
> > If
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe Eclipse is trying to run more of them at a time than ant, and the
> extra concurrency is killing the server for some reason. Was this
> compiled with Cygwin, or is it the native (mingw) version?
Don't both those builds have some hard-wired upper
Laurent Duperval wrote:
> On Mon, 15 Oct 2007 15:06:37 -0400, Kris Jurka wrote:
>
> >> I get en error in the logs that state:
> >>
> >> Server process exited with exit code -1073741502
> >
> > This is likely a server bug. If you can isolate the failing test and
> > extract a self contained exam
I will add that speed may be a factor also. When I increase the amount of
logging by the PG server, I see the problem less often.
L
On Mon, 15 Oct 2007 17:58:48 +, Laurent Duperval wrote:
> Hi,
>
> I have a large amount of tests I run in Eclipse to test my application.
> Many of them creat
On Mon, 15 Oct 2007 15:06:37 -0400, Kris Jurka wrote:
>> I get en error in the logs that state:
>>
>> Server process exited with exit code -1073741502
>
> This is likely a server bug. If you can isolate the failing test and
> extract a self contained example someone can probably fix it.
>
It
On Mon, 15 Oct 2007, Laurent Duperval wrote:
I have a large amount of tests I run in Eclipse to test my application.
Many of them create and delete a lot of information in PG and at some
point, PG will crash and restart.
I get en error in the logs that state:
Server process exited with exit
Hi,
I have a large amount of tests I run in Eclipse to test my application.
Many of them create and delete a lot of information in PG and at some
point, PG will crash and restart.
I get en error in the logs that state:
Server process exited with exit code -1073741502
.
.
.
Terminating connect
80 matches
Mail list logo