Re: PHJ file leak. - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: PHJ file leak.
Date
Msg-id CA+hUKGLGsM68afu7yy72u+858403iPWA_e7TYH2bj0VpYgynuw@mail.gmail.com
Whole thread Raw
In response to Re: PHJ file leak.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: PHJ file leak.  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Tue, Nov 12, 2019 at 5:03 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Nov 12, 2019 at 4:23 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > On Tue, Nov 12, 2019 at 4:20 PM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing dependency tracking for TableFunc nodes
Next
From: Tom Lane
Date:
Subject: Re: make pg_attribute_noreturn() work for msvc?