Re: GiST KNN Crasher

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: GiST KNN Crasher
Дата
Msg-id 555E47D5.8080000@iki.fi
обсуждение исходный текст
Ответ на Re: GiST KNN Crasher  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GiST KNN Crasher  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 05/21/2015 11:28 PM, Tom Lane wrote:
> Paul Ramsey <pramsey@cleverelephant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Fix misaligned access of ItemPointerData on ARM
Следующее
От: Geoff Winkless
Дата:
Сообщение: Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint