Re: GiST KNN Crasher

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GiST KNN Crasher
Date: 2015-05-21 21:02:13
Message-ID: 555E47D5.8080000@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/21/2015 11:28 PM, Tom Lane wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>> I'm implementing the recheck functionality for PostGIS so we can
>> support it when 9.5 comes out, and came across this fun little
>> crasher.
>
> Hmm, works in 9.3 and 9.4, so it's been broken recently.

It was clearly broken by knn-with-recheck patch (35fcb1b3), which added
the code where the segfault happened.

The find_ec_member_for_expr() call in create_indexscan_plan() fails to
find the equivalence member for the path key.
match_clause_to_ordering_op() found the match by commuting the operator,
but code in create_indexscan_plan() doesn't take that into account.

I think that trying to find the equivalence member in
create_index_scan() is too fragile. I'm not too familiar with the
equivalence class stuff though, so I'm not sure what the correct
solution is. Could we store the datatype in the IndexPath to begin with,
to avoid having to deduce it in create_indexscan_plan()? Or could we
just use exprType() on the expression in create_indexscan_plan() and not
bother finding the equivalence member? The comments in EquivalenceMember
suggest that that won't work in particular with anyarray_ops, but to be
honest this goes beyond my planner skills..

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Geoff Winkless 2015-05-21 21:03:26 Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint
Previous Message Andres Freund 2015-05-21 20:53:38 Re: Fix misaligned access of ItemPointerData on ARM