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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
