Re: [PATCH 1/1] Initial mach based shared memory support.

On 1/19/21 6:50 AM, James Hilliard wrote:
> On Mon, Jan 18, 2021 at 11:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
>>> from my understanding due to mach semantics a number of the sanity checks
>>> we are doing for sysv shmem are probably unnecessary when using mach
>>> API's due to the mach port task bindings(mach_task_self()) effectively
>>> ensuring our maps are already task bound and won't conflict with other tasks.
>>
>> Really? If so, this whole patch is pretty much dead in the water,
>> because the fact that sysv shmem is globally accessible is exactly
>> why we use it (well, that and the fact that you can find out how many
>> processes are attached to it). It's been a long time since we cared
>> about sysv shmem as a source of shared storage. What we really use
>> it for is as a form of mutual exclusion, i.e. being able to detect
>> whether any live children remain from a dead postmaster. That is,
>> PGSharedMemoryIsInUse is not some minor ancillary check, it's the main
>> reason this module exists at all. If POSIX-style mmap'd shmem had the
>> same capability we'd likely have dropped sysv altogether long ago.
>
> Oh, I had figured the mutual exclusion check was just to ensure that
> one didn't accidentally overlap an existing shared memory map.

At the very least, this patch does not seem to be ready for review, so I
have marked it Waiting on Author.

Since it appears the approach needs to be reconsidered, my
recommendation is to mark it Returned with Feedback at the end of the CF
so I'll do that unless there are objections.

Thanks,
--
-David
david(at)pgmasters(dot)net