From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Ian Barwick <ian(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible index issue on 9.5 slave |
Date: | 2014-06-19 03:35:15 |
Message-ID: | 12376.1403148915@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick <ian(at)2ndquadrant(dot)com> wrote:
>> Interesting, I'll take a look later.
> I'm pretty suspicious of incompatibilities that may exist between the
> two sets of OS collations involved here. We aren't very clear on the
> extent to which what you're doing is supported, but it's certainly the
> case that bttextcmp()/varstr_cmp()/strcoll() return values must be
> immutable between the two systems.
Oooh, I'll bet that's exactly it. Is the database using UTF8 encoding and
a non-C locale? It's well known that OS X's UTF8 locales sort nothing at
all like the supposedly equivalent locales on other systems.
> Still, it should be possible to
> determine if that's the problem using btreecheck.
Does btreecheck attempt to verify that the sort ordering of the index
matches the comparison behavior of the datatype? That would (in general)
require calling user-defined code, which seems like probably a pretty
bad idea for the purposes btreecheck is being advertised for.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-19 03:42:30 | Re: [bug fix] Memory leak in dblink |
Previous Message | Ian Barwick | 2014-06-19 03:34:31 | Re: Possible index issue on 9.5 slave |