From: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On-demand running query plans using auto_explain and signals |
Date: | 2015-09-18 11:22:16 |
Message-ID: | CACACo5S=mDFPoFrJPjMqKxT3GvFGHXTZj2Pfiza6WVNPR8bW5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-09-18 11:34:05 | Re: On-demand running query plans using auto_explain and signals |
Previous Message | Masahiko Sawada | 2015-09-18 11:14:35 | Re: Freeze avoidance of very large table. |