Re: Possible index issue on 9.5 slave - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Possible index issue on 9.5 slave
Date
Msg-id 12376.1403148915@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible index issue on 9.5 slave  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Possible index issue on 9.5 slave  (Peter Geoghegan <pg@heroku.com>)
Re: Possible index issue on 9.5 slave  (Ian Barwick <ian@2ndquadrant.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick <ian@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: Possible index issue on 9.5 slave
Next
From: Tom Lane
Date:
Subject: Re: [bug fix] Memory leak in dblink