Re: shmem_seq may be a bad idea

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 shmget failure ...

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

Sound good?

			regards, tom lane