Re: POSIX shared memory support

The comment on that method vexes me:
"This value is useful only while the file is open by at least one
process. If no processes have it open, the index may change the next
time the file is opened."

I wonder how this applies to directories. I.e. is a directory open if
a file in it is open? You could use the path of an arbitrary file in
that directory (like postgresql.conf) if this wasn't the case. We
would need to be sure it was already opened by postgres somehow
(which it should be).

Chris

On Feb 27, 2007, at 1:30 AM, Magnus Hagander wrote:

> 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?
>
> //Magnus