Re: Assertion failure in get_attstatsslot()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Assertion failure in get_attstatsslot()
Дата
Msg-id 5045.1278692202@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Assertion failure in get_attstatsslot()  (Bernd Helmle <mailings@oopsware.de>)
Ответы Re: Assertion failure in get_attstatsslot()  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Bernd Helmle <mailings@oopsware.de> writes:
> -- assertion failure
> EXPLAIN SELECT 1 FROM foo WHERE UPPER(value) = 'xyz';

> I tried it back from current -HEAD to 8.3.11 and managed to reproduce it 
> everywhere. Non-cassert builds are working correctly, so i'm not sure 
> wether this is an over-aggressive assert() or masks a problem from 
> somewhere else.

I can reproduce it back to 8.0, and I'm not sure it couldn't be done in
older branches with a slightly different test case :-(.

I think that at bottom the issue is that the planner plays fast and
loose with binary-compatible data types by being willing to strip off
RelabelType nodes whenever it's trying to arrive at selectivity
estimates.  This isn't something we can easily change, though.

I'm quite hesitant to remove that Assert from deconstruct_array(), but
it strikes me that an easy workaround is to make get_attstatsslot()
use ARR_ELEMTYPE(statarray) rather than the passed-in atttype.  This
at least moves the fast-and-looseness into a function that's basically
a creature of the planner, rather than fooling with a fundamental
utility like deconstruct_array().

If anybody feels really uncomfortable with that, we could add a
compensating "Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
atttype))" into get_attstatsslot().  Not sure if it's worth the cycles.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Admission Control
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().