Re: Possible index issue on 9.5 slave

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

In response to

Responses

Browse pgsql-hackers by date

  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