From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, 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-28 22:28:12 |
Message-ID: | 5609BEFC.5010204@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/18/15 5:05 AM, Shulgin, Oleksandr 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...
>
> So this has to be the responsibility of the reply sending backend in the
> end: to create and release the DSM *at some point*.
What's wrong with just releasing it at the end of the statement? When
the statement is done there's no point to reading it asynchronously anymore.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-28 22:34:24 | Re: No Issue Tracker - Say it Ain't So! |
Previous Message | Jim Nasby | 2015-09-28 22:09:15 | Re: No Issue Tracker - Say it Ain't So! |