Re: PHJ file leak.
От | Kyotaro Horiguchi |
---|---|
Тема | Re: PHJ file leak. |
Дата | |
Msg-id | 20191113.094243.355680252312295240.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: PHJ file leak. (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: PHJ file leak.
|
Список | pgsql-hackers |
At Wed, 13 Nov 2019 09:48:19 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in > 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. The phatch's shape looks better. Thanks. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: