Re: [PATCH] Make ENOSPC not fatal in semaphore creation

Mikhail <mp39590(at)gmail(dot)com> writes:
> On Sun, Oct 17, 2021 at 10:29:24AM -0400, Tom Lane wrote:
>> 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.

That hardly guarantees no collisions. If it did, we'd never have bothered
with the PGSemaMagic business or the IpcSemaphoreGetLastPID check.

>> Also, you haven't explained why the existing (and much safer) recycling
>> logic in IpcSemaphoreCreate doesn't solve your problem.

> semget() returns ENOSPC, so InternalIpcSemaphoreCreate doesn't return -1
> so the whole logic of IpcSemaphoreCreate is not checked.

Hmm. Maybe you could improve this by removing the first
InternalIpcSemaphoreCreate call in IpcSemaphoreCreate, and
rearranging the logic so that the first step consists of seeing
whether a sema set is already there (and can safely be zapped),
and only then proceed with creation.

I am, however, concerned that this'll just trade off one hazard for
another. Instead of a risk of failing with ENOSPC (which the DBA
can fix), we'll have a risk of kneecapping some other process at
random (which the DBA can do nothing to prevent).

I'm also fairly unclear on when the logic you propose would trigger
at all. If the sema set is already there, I'd expect EEXIST or
equivalent, not ENOSPC.

regards, tom lane