Re: Missing CHECK_FOR_INTERRUPTS in hash joins

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Missing CHECK_FOR_INTERRUPTS in hash joins
Date: 2017-02-15 02:16:36
Message-ID: CAEepm=1DZh2SGzdH_nWPO1eT72S_VHR6hqTp7SyA3Tn1oeaOvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 15, 2017 at 2:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Adding a C.F.I. inside this loop is the most straightforward fix, but
> I am leaning towards adding one in ExecHashJoinGetSavedTuple instead,
> because that would also ensure that all successful paths through
> ExecHashJoinOuterGetTuple will do a C.F.I. somewhere, and it seems good
> for that to be consistent. The other possibility is to put one inside
> ExecHashTableInsert, but the only other caller of that doesn't really need
> it, since it's relying on ExecProcNode to do one.

Would it also make sense to put one in the loop in
ExecHashIncreaseNumBatches (or perhaps
ExecHashJoinSaveTuple for symmetry with the above)? Otherwise you
might have to wait for a few hundred MB of tuples to be written out
which could be slow if IO is somehow overloaded.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-02-15 02:19:46 operator_precedence_warning vs make installcheck
Previous Message Michael Paquier 2017-02-15 02:16:09 Re: WAL consistency check facility