On Friday, November 6, 2015 10:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think this approach is generally reasonable, but I suggested
> parts of it, so may be biased. I would be interested in hearing
> the opinions of others.
Has anyone taken a close look at what happens if the two sides of
the merge join have different implementations of the same collation
name? Is there anything we should do to defend against the
problem?
We already face the issue of corrupted indexes when we have
different revisions of glibc on a primary and a standby or when the
OS on a server is updated, so this wouldn't be entirely a *new*
problem:
http://www.postgresql.org/message-id/BA6132ED-1F6B-4A0B-AC22-81278F5AB81E@tripadvisor.com
... but it would be a brand-new way to hit it, and we might be able
to spot the problem in a merge join by watching for rows being fed
to either side of the join which are not in order according to the
machine doing the join.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
