On Sun, Oct 17, 2021 at 10:29:24AM -0400, Tom Lane wrote:
> mp39...@gmail.com writes:
> > We might be in situation when we have "just enough" semaphores in the
> > system limit to start but previously crashed unexpectedly, in that case
> > we won't be able to start again - semget() will return ENOSPC, despite
> > the semaphores are ours, and we can recycle them, so check this
> > situation and try to remove the semaphore, if we are unable - give up
> > and abort.
>
> AFAICS, this patch could be disastrous. What if the semaphore in
> question belongs to some other postmaster?
Does running more than one postmaster on the same PGDATA is supported at
all? Currently seed for the semaphore key is inode number of PGDATA.
> Also, you haven't explained why the existing (and much safer) recycling
> logic in IpcSemaphoreCreate doesn't solve your problem.
The logic of creating semas:
218 /* Loop till we find a free IPC key */
219 for (nextSemaKey++;; nextSemaKey++)
220 {
221 pid_t creatorPID;
222
223 /* Try to create new semaphore set */
224 semId = InternalIpcSemaphoreCreate(nextSemaKey, numSems +
1);
225 if (semId >= 0)
226 break; /* successful
create */
InternalIpcSemaphoreCreate:
101 semId = semget(semKey, numSems, IPC_CREAT | IPC_EXCL |
IPCProtection);
102
103 if (semId < 0)
104 {
105 int saved_errno = errno;
106
[...]
113 if (saved_errno == EEXIST || saved_errno == EACCES
114 #ifdef EIDRM
115 || saved_errno == EIDRM
116 #endif
117 )
118 return -1;
119
120 /*
121 * Else complain and abort
122 */
123 ereport(FATAL, [...]
semget() returns ENOSPC, so InternalIpcSemaphoreCreate doesn't return -1
so the whole logic of IpcSemaphoreCreate is not checked.
