Re: The dangers of streaming across versions of glibc: A cautionary tale

On Thu, Aug 7, 2014 at 9:46 AM, Bruce Momjian <bruce(at)momjian(dot)us> 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