Skip site navigation (1) Skip section navigation (2)

Re: POSIX shared memory support

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Chris Marcellino <cmarcellino(at)apple(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: POSIX shared memory support
Date: 2007-02-27 09:30:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, Feb 27, 2007 at 01:09:46AM -0800, Chris Marcellino wrote:
> 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.

This cannot happen on windows - you cannot rename a directory which
someone has open files in. The infamous sharing violation error.

> 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,

Yes, you could use the fileindex value. You need that one and the volume
serial number, total of 64+32 bits of data.

So yeah, we cuold use that instead of the full path name if we want to.
The advantage of this one is that it's shorter, the advantage of the
full path name is that you can see where the backend is from.

However, in most cases you will be able to see where the backend is from
anyway, because it is likely to have some other file open in the data
directory, so maybe that isn't such a big point after all?


In response to


pgsql-patches by date

Next:From: Chris MarcellinoDate: 2007-02-27 09:36:26
Subject: Re: POSIX shared memory support
Previous:From: Chris MarcellinoDate: 2007-02-27 09:09:46
Subject: Re: POSIX shared memory support

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group