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
