On Mon, Feb 26, 2007 at 09:00:09PM -0800, Chris Marcellino wrote:

> There is also a Windows version of this patch included, which can  
> replace the current SysV-to-Win32 shared memory
> layer as it currently does not check for orphaned backends in the  
> database. If this is used,
> src/backend/port/win32/shmem.c and its makefile reference can be  
> removed.

This code is pretty close to the one I've been working on. Didn't
reliase you would be working on a win32 specific version, thought you
were doing POSIX only :-O

Anyway. My version does not use hashing of the name, it just puts the
name all the way in there. What are peoples feeling about that - win32
supports 32768 characters (though those are UTF16, so maybe the real
value is 16384 - still, if someone has his data directory that deep down
in a path, he deserves not to have it work). Should we be using hashing
or just plaintext there? I can see the argument for plaintext being that
you can then see in process explorer what data directory a backend is
connected to. But I'm open to arguments as to why a hash would be better

While looking at this, I noticed that Windows 2003 SP1 adds a parameter
SEC_LARGE_PAGES that enables "large pages to be used when mapping images
or backing from the pagefile". I would assume this is for performance
;-) Does anybody know anything more about this? Worth testing out to see
if it increases performance?

> The patches are available here (the postings were being silently  
> dropped when I attached this large of a file):

Actually, I don't think it's becauseo f the size of the file. Last time
I checked we still had a configuration which had the lists silently drop
certain file extensions, including .tar, .zip and .tar.gz. I've had
several patches dropped that way. I've had no confirmation it has been
fixed, so I'm assuming it's still a problem.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to