Re: On-demand running query plans using auto_explain and signals - Mailing list pgsql-hackers

From Robert Haas
Subject Re: On-demand running query plans using auto_explain and signals
Date
Msg-id CA+TgmoY4du07yA8x7fYrGarMp_Bf6bzaCAoHDL45_UO1iqvfyg@mail.gmail.com
Whole thread Raw
In response to Re: On-demand running query plans using auto_explain and signals  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
List pgsql-hackers
On Thu, Sep 17, 2015 at 12:47 PM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.de> wrote:
> But if we make the sender backend create the DSM with the response payload,
> it suddenly becomes really unclear at which point and who should make the
> final detach of that DSM.  We're getting back to the problem of
> synchronization between these processes all over again.

Yes, some thought is needed here.  There's not really a problem if
somebody asks for information just once: you could just have the
publishing process keep it attached until process exit, and nothing
bad would happen.  The real problem comes when multiple people ask for
information in quick succession: if you detach the old segment too
quickly after publishing it, the guy who requested that data might not
have attached it yet, and then when he gets around to looking at it,
it won't be there.

This seems like a pretty solvable problem, though.  For example, when
somebody asks for information, they store in the main shared segment a
pointer to their PGPROC and then they signal the target process, which
responds by publishing a dsm_segment_id.  When the requesting process
has accessed it, or when it errors out or exits, it clears the PGPROC
and the dsm_segment_id.  The publisher avoids unmapping it until that
happens.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: [patch] Proposal for \rotate in psql
Next
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan