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 wrote: James Hilliard 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 bin

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

On Sun, Nov 22, 2020 at 9:19 PM James Hilliard wrote: > In order to avoid hitting these limits we can bypass the wrapper layer > and just use mach directly. FWIW I looked into using mach_vm_alllocate() years ago because I wanted to be able to use its VM_FLAGS_SUPERPAGE_SIZE_2MB flag to implement

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

Peter Eisentraut writes: > This is the first I've heard in years of shared memory limits being a > problem on macOS. What settings or what levels of concurrency do you > use to provoke these errors? I suppose it wouldn't be too hard to run into shmmni with aggressive parallel testing; the defa

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

On 2020-11-22 09:19, James Hilliard wrote: OSX implements sysv shmem support via a mach wrapper, however the mach sysv shmem wrapper has some severe restrictions that prevent us from allocating enough memory segments in some cases. These limits appear to be due to the way the wrapper itself is i

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

On Mon, Jan 18, 2021 at 11:12 PM Tom Lane wrote: > > James Hilliard 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()) effecti

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

James Hilliard 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 co

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

On Mon, Jan 18, 2021 at 5:29 PM Tom Lane wrote: > > James Hilliard writes: > > OSX implements sysv shmem support via a mach wrapper, however the mach > > sysv shmem wrapper has some severe restrictions that prevent us from > > allocating enough memory segments in some cases. > > ... > > In order

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

On Mon, Jan 18, 2021 at 5:29 PM Tom Lane wrote: > > James Hilliard writes: > > OSX implements sysv shmem support via a mach wrapper, however the mach > > sysv shmem wrapper has some severe restrictions that prevent us from > > allocating enough memory segments in some cases. > > ... > > In order

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

James Hilliard writes: > OSX implements sysv shmem support via a mach wrapper, however the mach > sysv shmem wrapper has some severe restrictions that prevent us from > allocating enough memory segments in some cases. > ... > In order to avoid hitting these limits we can bypass the wrapper layer >

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

OSX implements sysv shmem support via a mach wrapper, however the mach sysv shmem wrapper has some severe restrictions that prevent us from allocating enough memory segments in some cases. These limits appear to be due to the way the wrapper itself is implemented and not mach. For example when ru