Alfred Perlstein <bright@wintelcom.net> writes:
> * Tom Lane <tgl@sss.pgh.pa.us> [010306 10:10] wrote:
>> The shmem key is driven primarily by port number
>> not data directory ...)
> This seems like a mistake.
> I'm suprised you guys aren't just using some form of the FreeBSD
> ftok() algorithm for this:
This has been discussed before --- see the archives. The conclusion was
that since ftok doesn't guarantee uniqueness, it adds nothing except
lack of predictability to the shmem key selection process. We'd still
need logic to cope with key collisions, and given that, we might as well
select keys that have some obvious relationship to user-visible
parameters, viz the port number. As is, you can fairly easily tell
which shmem segment belongs to which postmaster from the shmem key;
with ftok-derived keys, you couldn't tell a thing.
>> Comments? Does anyone see a better way to do it?
> What about encoding the shm id in the pidfile? Then one can just ask
> how many processes are attached to that segment? (if it doesn't
> exist, one can assume all backends have exited)
Hmm ... that might actually be a pretty good idea. A small problem is
that the shm key isn't yet selected at the time we initially create the
lockfile, but I can't think of any reason that we could not go back and
append the key to the lockfile afterwards.
> you want the field 'shm_nattch'
Are there any portability problems with relying on shm_nattch to be
available? If not, I like this a lot...
regards, tom lane
