Re: single task postgresql

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: single task postgresql
Date: 2002-02-27 15:33:00
Message-ID: 3C7CFC2C.3000402@copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Windows does not really have shared memory support. This has been a
beef with the Win32 API for a long time now. Because it has been a long
time complaint, it was finally added in Win2000 and later. Likewise,
I'd like to point out that thinks like sims, shared memory, pipes, etc,
and other entities commonly used for concurrent programming strategies
are slower in XP. So, because shared memory really isn't well
supported, they elected to have what is, in essense, memory mapped
files. Multiple processes then map the same file and read/write to it
as needed, more or less as you would shared memory. Unless you plan on
only targetting on Win 2000 and XP, it sounds like a waste of time.

As for your shared memory interface, I suspect you'll find up with
pretty much what the cygwin guys have. Your implementation may prove to
be slightly lighter as they may of had some other issues to address but
I doubt yours would prove to be much of a difference from a performance
perspective as it's still going to be pretty much the same thing under
the covers for most of the Win32 platforms. Also, expect to be taking a
performance hit with XP as is so I can't say targetting that platform
makes much sense, IMOHO.

Here's from MSDN:

CreateSharedMemory
The CreateSharedMemory function creates a section of memory that is
shared by client processes and the security package.

PVOID NTAPI CreateSharedMemory (
ULONG MaxSize,
ULONG InitialSize
);
Parameters
[in] MaxSize
Specifies the maximum size of the shared memory.
[in] InitialSize Specifies the initial size of the shared memory.
Return Values
The function returns a pointer to the block of shared memory, or NULL if
the block was not reserved.

Remarks
Creating a shared section for each client is not advisable because it is
a very expensive operation and may exhaust system resources.

The package's clients can write to shared memory which makes it
susceptible to attack. Data in the shared segment should not be trusted.

The pointer returned by the CreateSharedMemory function is required by
the AllocateSharedMemory, DeleteSharedMemory, and FreeSharedMemory
functions.

Use the DeleteSharedMemory function to release memory reserved by the
CreateSharedMemory function.

Pointers to these functions are available in the
LSA_SECPKG_FUNCTION_TABLE structure received by the SpInitialize function.

Requirements
Windows NT/2000 or later: Requires Windows 2000 or later.
Header: Declared in Ntsecpkg.h.

Here's an except from Python's Win32 API:

Memory Mapped Files

Access to Win32 Memory Mapped files. Memory mapped files allow efficient
sharing of data between separate processes. It allows a block of
(possibly shared) memory to behave like a file.

This was just thrown in to show that memory mapped files are the
standard for shared memory on Win32 systems. Likewise, I'd like to
point out that I've not seen anything published that would suggest that
shared memory versus memory mapped files via the Win32 API should yield
a higher performance.

Greg

mlw wrote:
> Oleg Bartunov wrote:
>
>>we have to support earlier windows which have no shared memory support.
>>
>
> I'm pretty sure it could a configuration option then. Using a file is just
> plain stupid. "Every" version of Windows has supported shared memory in one
> form or another.
>
> What version are you wishing to support which the cygwin guys claim does not
> have shared memory?
>
> I'm prety sure I can write a shared memory interface for Windows which should
> work across all "supported" versions.
>
> (BTW I have been a Windows developer since version 1.03.)
>
>
>
>
>>On Tue, 26 Feb 2002, mlw wrote:
>>
>>
>>>Oleg Bartunov wrote:
>>>
>>>>Having frustrated with performance on Windows box I'm wondering if it's
>>>>possible to get postgresql optimized for working without shared memory,
>>>>say in single-task mode. It looks like it's shared memory emulation on disk
>>>>(by cygipc daemon) is responsible for performance degradation.
>>>>In our project we have to use Windows for desktop application and it's
>>>>single task, so we don't need shared memory. In principle, it's possible
>>>>to hack cygipc, so it wouldn't emulate shared memory and address calls
>>>>to normal memory, but I'm wondering if it's possible from postgres side.
>>>>
>>>> Regards,
>>>>
>>>How does cygwin do shared memory on Windows? Windows support real shared
>>>memory, surely the cygwin guys are using "real" shared memory. Are you sure
>>>that this is the problem? If so, might we not be able to use a few
>>>macros/#ifdefs to do it right?
>>>
>>>I'll be up for that if you guys don't mind some "ifdef/endif" stuff here and
>>>there.
>>>
>>>
>> Regards,
>> Oleg
>>_____________________________________________________________
>>Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
>>Sternberg Astronomical Institute, Moscow University (Russia)
>>Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
>>phone: +007(095)939-16-83, +007(095)939-23-83
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
--------------------------------------------------
PGP/GPG Key at http://www.keyserver.net
5A66 1470 38F5 5E1B CABD 19AF E25A F56E 96DC 2FA9
--------------------------------------------------

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2002-02-27 15:38:02 Re: single task postgresql
Previous Message Rod Taylor 2002-02-27 15:24:26 Re: Refactoring of command.c