I believe that all we need is the ID to be constant and unique while
the postmaster or its associated backends are running. If anything
from a given generation has the database open, it will remain
constant before any new process can connect to it successfully. Would
it be feasible to lookup the ID of an important file in the DataDir?
As far as the POSIX version goes, here is an updated patch. I changed
it to use the inode/device ID instead of the filename to avoid the
renaming cases. It also no longer needs the more clunky than
necessary hash stuff.
(The NetBSD/OpenBSD patches are to force those to build with the SysV
shmem calls, since they are notably without POSIX shmem support.)
Thanks,
Chris Marcellino
On Feb 27, 2007, at 1:40 AM, Magnus Hagander wrote:
> On Tue, Feb 27, 2007 at 10:30:15AM +0100, Magnus Hagander wrote:
>>> 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?
>
> Actually, I'm not sure we can. It's only stable as long as someone has
> the file open. It will change if it's closed and re-opened later.
>
> Given that we don't actually open the directory, and only files inside
> it, I don't know how that works.
>
> //Magnus
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
