Peter Eisentraut <peter_e@gmx.net> 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.
But that seems like it'd resolve both the wrong-size issue and the
conflict-with-another-program issue. I like it.
>> The intent of this logic is evidently to ensure that the old, failed
>> backends can't somehow corrupt the new ones.
> But what if someone runs another postmaster at port 5433, will it
> eventually interfere?
No; I neglected to mention that shmem_seq wraps around at 10. So
there's no possible conflict between postmasters at different port#s
in the current scheme.
> Or some totally different program?
That, on the other hand, is a very real risk. Trying a new key if we
fail to get a new shmem seg (or semaphore set) seems like a good
recovery method.
We'd need to rejigger the meaning of shmem_seq a little bit --- it'd
no longer be a global variable, but rather a local count of the number
of tries to create a particular seg or set. So, logic would be
something like
for (seq = 0; seq < 10; seq++) { key = port*1000 + seq*100 + (id for particular item); shmctl(key, IPC_RMID, 0);
// ignore error shmget(key, size, IPC_CREAT | IPC_EXCL); if (success) return key;}// if get here, report
shmgetfailure ...
It looks like we can apply the same method for semaphore sets, too.
Sound good?
regards, tom lane
