Re: Wrong Results from SP-GiST with Collations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Emre Hasegeli <emre(at)hasegeli(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Wrong Results from SP-GiST with Collations
Date: 2018-04-16 18:51:06
Message-ID: 19693.1523904666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> Has the operator class really been completely broken since SP-GiST was
> first introduced? I tend to doubt that. spg_text_inner_consistent()
> has the following code, which appears to acknowledge the problem with
> non-C collations:

You're on to something, but I think the bug is in
spg_text_leaf_consistent, which thinks it can do collation-aware
comparisons like this:

r = varstr_cmp(fullValue, Min(queryLen, fullLen),
VARDATA_ANY(query), Min(queryLen, fullLen),
PG_GET_COLLATION());

That's got nothing to do with reality for non-C collations, and it seems
rather pointless anyway, Why isn't this just

r = varstr_cmp(fullValue, fullLen,
VARDATA_ANY(query), queryLen,
PG_GET_COLLATION());

and then the bit below about

if (r == 0)
{
if (queryLen > fullLen)
r = -1;
else if (queryLen < fullLen)
r = 1;
}

needs to move into the "non-collation-aware" branch.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2018-04-16 19:19:36 Re: Wrong Results from SP-GiST with Collations
Previous Message Peter Geoghegan 2018-04-16 18:35:05 Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre