On Thu, Aug 7, 2014 at 9:46 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: > We could walk the index looking for inconsistent btree splits, e.g. the > split doesn't match the ordering returned by the existing collation > functions. I'm not sure I follow. I don't think that a tool like my btreecheck tool will necessarily be able to catch anything like this on a standby. Maybe it will, but that isn't guaranteed. For example, the difference in collation rules in question might just not have cropped up yet, but it's still a ticking time-bomb. Or, there are only differences affecting values on internal pages. Things break down very quickly. In general, once there is an undetected inconsistency in collations between replicas, that means that the varlena B-Tree support function number 1 can violate various invariants that all operator classes must obey. I doubt we want to get into the business of working backwards from a broken state of affairs like that to figure out there is a problem. Rather, I really do think we're compelled to offer better versioning of collations using a versioning interface like Glibc's LC_IDENTIFICATION. There is no way other way to properly fix the problem. This is a problem that is well understood, and anticipated by the Unicode consortium. -- Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
