On Friday, November 6, 2015 10:32 AM, Robert Haas <robertmh...@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-81278f5ab...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
