Re: PHJ file leak.

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: PHJ file leak.
Date: 2019-11-12 20:48:19
Message-ID: CA+hUKGLGsM68afu7yy72u+858403iPWA_e7TYH2bj0VpYgynuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 12, 2019 at 5:03 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Nov 12, 2019 at 4:23 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Tue, Nov 12, 2019 at 4:20 PM Kyotaro Horiguchi
> > <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > > The previous patch would be wrong. The root cause is a open batch so
> > > the right thing to be done at scan end is
> > > ExecHashTableDeatchBatch. And the real issue here seems to be in
> > > ExecutePlan, not in PHJ.
> >
> > You are right. Here is the email I just wrote that says the same
> > thing, but with less efficiency:
>
> And yeah, your Make_parallel_shutdown_on_broken_channel.patch seems
> like the real fix here. It's not optional to run that at
> end-of-query, though you might get that impression from various
> comments, and it's also not OK to call it before the end of the query,
> though you might get that impression from what the code actually does.

Here's the version I'd like to commit in a day or two, once the dust
has settled on the minor release. Instead of adding yet another copy
of that code, I just moved it out of the loop; this way there is no
way to miss it. I think the comment could also be better, but I'll
wait for the concurrent discussions about the meaning of
ExecShutdownNode() to fix that in master.

Attachment Content-Type Size
0001-Make-sure-we-call-ExecShutdownNode-if-appropriate.patch application/octet-stream 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-11-12 20:55:06 Re: BUG #16109: Postgres planning time is high across version - 10.6 vs 10.10
Previous Message PG Bug reporting form 2019-11-12 20:34:35 BUG #16109: Postgres planning time is high across version - 10.6 vs 10.10