Re: shmem_seq may be a bad idea

Peter Eisentraut <peter_e(at)gmx(dot)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 shmget failure ...

It looks like we can apply the same method for semaphore sets, too.

Sound good?

regards, tom lane