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