Subject: Re: On-demand running query plans using auto_explain and
 signals
To: "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>, Pavel Stehule
 <pavel.stehule@gmail.com>
References: 
 <CACACo5Sz7G0MFauC082iM=XX_hQ7qQ5ndR4JPo+H-O5vp6iCcQ@mail.gmail.com>
 <55F6B95E.4080507@2ndquadrant.com>
 <CACACo5SKOxdPJ54MwNxuK0CdHf7pp3mB5eN-Ha5e4WDg9i1Ksw@mail.gmail.com>
 <CACACo5TedzSJpdrZzjwpkw3i6a8PH2TdLvWzmpf2S719KQnwPQ@mail.gmail.com>
 <CAFj8pRA_yTPDtZcaf=kLE-PD-AZg19s8_OKFd5AwLt+EcgA68g@mail.gmail.com>
 <CACACo5QW3CAUcyQ8yFJzwrvX6JXkqaekr3eB11-AmnBYDtaM_A@mail.gmail.com>
 <CA+Tgmobu1DvQzahsSX=u9Ti=g4zJmxNmaNHC2-ru8sGBxmtvbw@mail.gmail.com>
 <CAFj8pRAk7EiGO9-GDR5rK7rDh76okyYKP5kDAOMHaRyJ_XCvsw@mail.gmail.com>
 <CA+TgmoYn2SF0qxSxC=Q_8Sm3M2CaPh6hpedi0SqNTxymetmcfA@mail.gmail.com>
 <CAFj8pRAB4otjEtv2eEkEyX1YCmDg+5JCEH0GeabKosjopN52Cw@mail.gmail.com>
 <CA+TgmoYjkGXvywwm9qoODkU1UJZweshDdCUREd-rsvab75oecQ@mail.gmail.com>
 <CACACo5Q=nEEzAUE3o29WTU0wW7wourZB+SDhwPYzGZPyggF4hg@mail.gmail.com>
 <CAFj8pRAENjXoLQp+_nRZXuqzn7kJRx7YUScD6O=yczmi1CU3qQ@mail.gmail.com>
 <CACACo5QSG0yy9dD_Ots8Zy+djvSOrfwfmU-wC+y8HPgo4tzoqg@mail.gmail.com>
CC: Robert Haas <robertmhaas@gmail.com>, Tomas Vondra
 <tomas.vondra@2ndquadrant.com>, PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <5609BEFC.5010204@BlueTreble.com>
Date: Mon, 28 Sep 2015 17:28:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
 <CACACo5QSG0yy9dD_Ots8Zy+djvSOrfwfmU-wC+y8HPgo4tzoqg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: bluetreble.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2015 22:28:17.4686 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR11MB0680
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers