pgsql-hackers
❮
Assert failure in _bt_preprocess_array_keys
- Jump to comment-1Richard Guo<guofenglinux@gmail.com>Apr 22, 2024, 2:36 AM UTCI came across an assert failure in btpreprocessarraykeys regarding
the sanity check on the datatype of the array elements. It can be
reproduced with the query below.
create table t (c int4range);
create unique index on t (c);
select * from t where c in ('(1, 100]'::int4range, '(50, 300]'::int4range);
It fails on this Assert:
+ elemtype = cur->sk_subtype;
+ if (elemtype == InvalidOid)
+ elemtype = rel->rdopcintype[cur->skattno - 1];
+ Assert(elemtype == ARR_ELEMTYPE(arrayval));
... which was introduced in 5bf748b86b.
I didn't spend much time digging into it, but I wonder if this Assert is
sensible. I noticed that before commit 5bf748b86b, the two datatypes
were not equal to each other either (anyrange vs. int4range).
Thanks
Richard- Jump to comment-1Peter Geoghegan<pg@bowt.ie>Apr 22, 2024, 2:52 AM UTCOn Sun, Apr 21, 2024 at 10:36 PM Richard Guo <guofenglinux@gmail.com> wrote:
I didn't spend much time digging into it, but I wonder if this Assert is
The assertion is wrong. It is testing behavior that's much older than
sensible. I noticed that before commit 5bf748b86b, the two datatypes
were not equal to each other either (anyrange vs. int4range).
commit 5bf748b86b, though. We can just get rid of it, since all of the
information that we'll actually apply when preprocessing scan keys
comes from the operator class.
Pushed a fix removing the assertion just now. Thanks for the report.
--
Peter Geoghegan- Jump to comment-1Richard Guo<guofenglinux@gmail.com>Apr 22, 2024, 6:22 AM UTCOn Mon, Apr 22, 2024 at 10:52 AM Peter Geoghegan <pg@bowt.ie> wrote:
On Sun, Apr 21, 2024 at 10:36 PM Richard Guo <guofenglinux@gmail.com>
wrote:
I didn't spend much time digging into it, but I wonder if this Assert is
sensible. I noticed that before commit 5bf748b86b, the two datatypes
were not equal to each other either (anyrange vs. int4range).
That's so quick. Thank you for the prompt fix.
The assertion is wrong. It is testing behavior that's much older than
commit 5bf748b86b, though. We can just get rid of it, since all of the
information that we'll actually apply when preprocessing scan keys
comes from the operator class.
Pushed a fix removing the assertion just now. Thanks for the report.
Thanks
Richard