The Win32 version didn't materialize until very recently. The Win32 calls are similar semantically to the POSIX ones, so it was somewhat straightforward.

Plaintext is nice if you can fit it, since Windows permits you to have slashes and all sorts of other non-filename characters in them, unlike POSIX shmem. Also for POSIX, certain platforms (ahem Darwin has 30 chars) have very small segment name limits. As Tom said, the renaming-while-running issue might be a deal breaker, but I'm not sure that is a problem on Windows. It sounds like you are on the right track.


I just mentioned this to Tom, but a solution for POSIX might be to use the device and inode combination for the data directory, since that is constant across renames and is more certain to be unique. Like replacing the GenerateIPCName() function with something this:

static void
GenerateIPCName(char destIPCName[IPCSegNameLength])
{
        struct          stat statbuf;
        
        /* Get the data directory's device and inode */
        if (stat(DataDir, &statbuf) < 0)
                ereport(FATAL,
                                (errcode_for_file_access(),
                                 errmsg("could not stat data directory \"%s\": 
%m",
                                                DataDir)));
        
        /*
         * POSIX requires that shared memory names begin with a single slash.
         * They should not have any others slashes or any non-alphanumerics to
         * maintain the broadest assumption of what is permitted in a filename.
         * Also, case sensitivity should not be presumed.
         */
        snprintf(destIPCName, IPCSegNameLength, "/PostgreSQL.%jx.%jx",
                         (intmax_t) statbuf.st_dev, (intmax_t) statbuf.st_ino);
}


Does Windows have a method to get a unique ID number for a given data directory, or a token file in that directory? It would need to be constant while the database is open. Perhaps GetFileInformationByHandle? It returns a struct with a nFileIndex value that seems to be that, although I'm not certain. This might make it easier to avoid the complexity of fitting the filename in the segment name, and avoid the rename problem,

Thanks,
Chris Marcellino




On Feb 27, 2007, at 12:56 AM, Magnus Hagander wrote:

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.

//Magnus


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to