Re: BUG #12908: tstzrange constructor fails when used in WHERE clause
От | Tom Lane |
---|---|
Тема | Re: BUG #12908: tstzrange constructor fails when used in WHERE clause |
Дата | |
Msg-id | 21189.1427822278@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #12908: tstzrange constructor fails when used in WHERE clause (rward@uberlogik.com) |
Ответы |
Re: BUG #12908: tstzrange constructor fails when used in WHERE clause
|
Список | pgsql-bugs |
rward@uberlogik.com writes: > Queries that construct a tstzrange in the where clause fail with the error > message "ERROR: range lower bound must be less than or equal to range upper > bound. SQL state: 2200". This error happens despite the fact that the range > bounds are correct (i.e. lower bound < upper). > Simplest example of a query that would fail with this error: > select period from foo > where period && tstzrange('2015-03-25 12:00:00+00'::timestamptz, '2015-03-26 > 12:00:00+00'::timestamptz, '[]') > However, I can't seem to reproduce the conditions that trigger this bug. > Once that unknown condition is triggered though, the incorrect behavior > described above happens every time. I'm suspicious that the triggering event for this is a type cache flush; but it's hard to see how that would work exactly, because typcache.c never flushes the cache fields for range-type properties. Still, you might work on the assumption that the user-level triggering event is some DDL operation that affects a type definition --- not necessarily one with any direct connection to the failing query --- and see if you can get to a repeatable way to reproduce the issue. Also, once you've gotten a backend into the failing state, it would be useful to attach to it with gdb, set a breakpoint at errfinish, and get a stack trace from the point of the error report. The error must be coming from range_serialize, but it might be a mistake to assume that the direct caller of that is the tstzrange() constructor. (This line of thought would lead to the idea that there's bad statistics for a range column, or some other mechanism that would cause the planner to try to construct a bogus range value on its way to calculating selectivity estimates. In that case, just doing an ANALYZE might cause the error to appear or disappear.) regards, tom lane
В списке pgsql-bugs по дате отправления: