Windows SHMMAX (was: Default configuration)

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Windows SHMMAX (was: Default configuration)
Date: 2003-02-11 18:49:17
Message-ID: 303E00EBDD07B943924382E153890E5434A90A@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Does anyone know whether cygwin has a setting comparable to SHMMAX,
and if so what is its default value? How about the upcoming native
Windows port --- any issues there?

From a pure win32 point of view, a good approach would be to use the
VirtualAlloc() memory allocation functions and set up a paged memory
allocation system. From a very top down point of view, this is the
method of choice if portability is not an issue. An abstraction to use
this technique within pg context is probably complex and requires
writing lots of win32 api code, which is obviously not desirable.

Another way of looking at it is memory mapped files. This probably most
closely resembles unix shared memory and is the de facto standard way
for interprocess memory block sharing. Sadly, performance will suffer
because you have to rely on the virtual memory system (think: writing to
files) to do a lot of stupid stuff you don't necessarily want or need.
The OS has to guarantee that the memory can be swapped out to file at
any time and therefore mirrors the pagefile to the allocated memory
blocks.

With the C++/C memory malloc/free api, you are supposed to be able to
get some of the benefits of virtual alloc (in particular, setting a
process memory allocation limit), but personal experience did not bear
this out. However, this api sits directly over the virtual allocation
system and is the most portable. The application has to guard against
fragmentation and things like that in this case. In win32, server
thrashing is public enemy #1 for database servers, mostly due to the
virtual allocation system (which is quite fast when used right, btw).

Merlin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew T. O'Connor 2003-02-11 18:53:51 Re: Changing the default configuration (was Re: [pgsql-advocacy]
Previous Message mlw 2003-02-11 18:44:15 location of the configuration files