Re: On-demand running query plans using auto_explain and signals

2015-09-18 13:22 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:

> On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr(dot)shulgin(at)zalando(dot)de>:
>>
>>> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>
>