2015-09-18 13:22 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule <pavel.steh...@gmail.com >>> > wrote: >>> >>>> >>>> It should not be true - the data sender create DSM and fills it. Then >>>> set caller slot and send signal to caller. Caller can free DSM any time, >>>> because data sender send newer touch it. >>>> >>> >>> But the requester can timeout on waiting for reply and exit before it >>> sees the reply DSM. Actually, I now don't even think a backend can free >>> the DSM it has not created. First it will need to attach it, effectively >>> increasing the refcount, and upon detach it will only decrease the >>> refcount, but not actually release the segment... >>> >> >> I am afraid so it has not simple and nice solution - when data sender >> will wait for to moment when data are received, then we have same >> complexity like we use shm_mq. >> >> Isn't better to introduce new background worker with responsibility to >> clean orphaned DSM? >> > > I'm not thrilled by this idea. > > We don't even need a worker to do that, as leaked segments are reported by > the backend itself upon transaction commit (see > ResourceOwnerReleaseInternal), e.g: > > WARNING: dynamic shared memory leak: segment 808539725 still referenced > > Still I believe relying on some magic cleanup mechanism and not caring > about managing the shared memory properly is not the way to go. > It was one my idea too, to check shared memory on exit. The disadvantage is clean - some times you can wait too long - although the very practical limit for session is about 2h. > > -- > Alex > >
