Re: shmem_seq may be a bad idea

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>>>> Why not use IPC_EXCL to ensure you're getting a freshly baked shmem
>>>> segment rather than a recycled one?
>> 
>> Hmm, that might work --- we'd need to add some logic to try to delete
>> a conflicting segment and/or move on to another key if we can't.

> How about you just pick a key (preferably using a standard method such as
> ftok, but the current is fine as well if you like the traceability of keys
> to servers) and if it's already used then increase it by one, try again.

The thing I don't like about using ftok() is that it opens you up to
cross-postmaster conflicts, if there's more than one postmaster running
on the same machine.  Since ftok is so weakly specified, we have no way
to be sure that two different postmasters wouldn't generate the same
key.

As for the issue of whether to try to delete or not, we don't have
automatic cleanup of no-longer-used segments unless we try to delete.
That's why it's critical that we not have cross-postmaster conflicts.
The skeleton code I exhibited yesterday depends on the assumption that
any segment/semset that the postmaster has permission to delete is OK
for it to delete.  If there is a possibility of cross-postmaster
collision then that doesn't work anymore.

(Of course, if the postgres account also runs non-postgres applications
that use shmem or semas, you could have trouble anyway ... but that
seems unlikely, and perhaps more to the point it's pretty easy to avoid
*as long as postgres generates predictable keys*.  With ftok the keys
aren't predictable, and you're trusting to luck that you don't have a
collision.)

> A while ago while thinking about a way to make ipcclean better I thunk
> that perhaps the postmaster should write the keys of the segments it gets
> to a flat-text file. If it somehow crashes and loses track of what it
> allocated before it can use that information to clean up.

We could do that, but I'm not sure it's necessary.  With the code I
proposed, the segments would essentially always have the same keys,
and so restarting the postmaster would clean up automatically.  (The
only time the sequence number would get above 0 would be if you had
a collision with an ftok-using app, and presumably on your next try
you'd get the same collision and end up with the same final choice
of sequence number ...)
        regards, tom lane