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

On 10/23/07, Harald Armin Massa <haraldarminmassa@gmail.com> 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 that
> > "desktop".
>
> Using this knowledge and Daves response, also looking back at "3,2kb
> per backend", I stumbled upon that KB entry:
>
> http://support.microsoft.com/?scid=kb%3Ben-us%3B184802&x=15&y=14

[...]

> 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.

It's not quite what you think.  The link Rainer posted upthread does a
decent job describing it, although there's still some room for
confusion: http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx

The hierarchy of containers goes Session, Window Station, Desktop.
Everything relevant is under the same Session, so I'll ignore that for
now.

The console gets a Window Station; this is the interactive one since
the user sitting down works with it directly.  It normally contains
one Desktop of interest (Default), which is what the user actually
sees.  (It's possible to create multiple desktops as a framework for a
"virtual desktop" type of thing, but that's all third-party stuff.)

Each service registered with the Service Manager has a specific
account it logs in under.  For each account, the Service Manager
creates a Window Station to contain it, and all services using the
same account share the default Desktop inside it.  Most services run
under one of the 3 canned accounts, which is what that KB article is
talking about with the Local System bit.

Each Desktop created has a fixed-size chunk of memory allocated to it.
 Desktops created under the interactive Window Station get the larger
chunk of memory (3072KB) since they expect to contain lots of UI
stuff.  Desktops created under other Window Stations get the smaller
chunk of memory (512KB), since they aren't presenting a UI to the
user.

That fixed-size desktop heap is used to track objects handled by the
USER subsystem, which is mostly UI elements like windows and such.
Most of the API interaction for those resources go through user32.dll,
and apparently its initialization procedure grabs some of that heap
space for each process it's loaded into.

The PostgreSQL service is set to log in under its own account, so it
gets its own Window Station, and a default Desktop inside that.  This
is a non-interactive Window Station, so the Desktop gets the smaller
heap.  All postgres.exe processes run in that Desktop and share one
512KB heap.  As each process ends up carving out a chunk of that
space, it uses up all 512KB and fails to create more backends.