Re: [HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins
Date
Msg-id CAEepm=1DZh2SGzdH_nWPO1eT72S_VHR6hqTp7SyA3Tn1oeaOvA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 15, 2017 at 2:22 PM, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] WAL consistency check facility
Next
From: Jeff Janes
Date:
Subject: [HACKERS] operator_precedence_warning vs make installcheck