Re: bytea operator bugs (was Re: [GENERAL] BYTEA, indexes and "like")

Joe Conway <mail@joeconway.com> writes:
> The first was an assert failure in patternsel(). It was looking for
> strictly TEXT as the right-hand const. I guess when I originally did the
> bytea comparison operators last year I didn't have assert checking on :(
> In any case attached is a small patch for that one.

This is not gonna fly: the reason why that Assert is there is that
the rest of the pattern-analysis code assumes it can work with
null-terminated strings.  If you want a one-line patch then the patch
is to change the right-hand argument of bytealike to TEXT.  A "real"
patch would probably require changing all the patternsel routines to
use counted strings, which seems like it will add major uglification.


> I've isolated this down to _bt_getroot() to the following line (about
> line 125 in nbtpage.c):

>     if (!(metaopaque->btpo_flags & BTP_META) ||
>         metad->btm_magic != BTREE_MAGIC)
>         elog(ERROR, "Index %s is not a btree",
>              RelationGetRelationName(rel));

> and more specifically to "!(metaopaque->btpo_flags & BTP_META)".
> But I haven't been able to see any difference between the bytea case
> which fails, and text or varchar which do not.

I'm betting on a memory-clobber kind of problem --- I think something in
the bytea-related code is stomping on the disk buffer that holds the
btree metapage.  Are you testing with --enable-cassert now?  (That turns
on MEMORY_CHECKING which might be helpful...)

            regards, tom lane