Re: Shouldn't ExecShutdownNode() be called from standard_ExecutorFinish()?

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shouldn't ExecShutdownNode() be called from standard_ExecutorFinish()?
Date: 2018-10-04 04:15:54
Message-ID: CAA4eK1K1tJuDtCqjefuLUmn-sNjUB5ARF44XPd6KxSUcwFc_XQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 4, 2018 at 12:33 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> There's a few cases where by the time ExecutorFinish() is called,
> ExecShutdownNode() has not yet been called. As, among other reasons,
> ExecShutdownNode() also collects instrumentation, I think that's
> problematic.
>
> In ExplainOnePlan() we call
>
> /* run cleanup too */
> ExecutorFinish(queryDesc);
>
> and then print the majority of the explain data:
>
> /* Create textual dump of plan tree */
> ExplainPrintPlan(es, queryDesc);
>
> and only then shut down the entire query:
>
> ExecutorEnd(queryDesc);
>
> which seems to mean that if a node hasn't yet been shut down for some
> reason, we'll not have information that's normally collected in
> ExecShutdownNode().
>

Ideally, ExecShutdownNode would have been called by the end of
ExecutorRun phase. Can you tell which particular case you are
bothered about?

> ISTM, we should have a new EState member that runs ExecShutdownNode() if
> in standard_ExecutorEnd() if not already done.
>

Even if it wasn't called before due to any reason, I think the
relevant work should be done via
standard_ExecutorEnd->ExecEndPlan->ExecEndNode. For example, for
gather node, it will call ExecEndGather to perform the necessary work.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ideriha, Takeshi 2018-10-04 04:27:04 RE: Protect syscache from bloating with negative cache entries
Previous Message David Rowley 2018-10-04 03:19:56 Re: [HACKERS] Secondary index access optimizations