Re: Getting sorted data from foreign server for merge join - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Getting sorted data from foreign server for merge join
Date
Msg-id CAFjFpRdDOzOvgt2Nh+ZgOfBkhoFKv26GKyXGYvb4Cw3-Wqk0KA@mail.gmail.com
Whole thread Raw
In response to Re: Getting sorted data from foreign server for merge join  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Getting sorted data from foreign server for merge join  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers


On Mon, Nov 9, 2015 at 9:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> 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?

The issue of FDWs vs. collations has been thought about to some degree
(see FDW_COLLATE_NONE/SAFE/UNSAFE), but I don't quite understand that
stuff in detail> .
>

collations arising from a foreign table's var are considered to be safer (FDW_COLLATE_SAFE) to push down to the foreign server , since they are either local default collation or are assumed to be same on foreign and local server as per user declaration. The onus of making that sure is on the user who declares particular collation for a foreign table var. As said upthread, different glibc implementations can cause collation ordering mismatch, this patch will be susceptible to the same problem as master/standby problem.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change
Next
From: Simon Riggs
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data