| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, david(dot)kohn(at)moat(dot)com |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Varying results when using merge joins over postgres_fdw vs hash joins |
| Date: | 2017-09-20 16:18:46 |
| Message-ID: | CADkLM=cUQTm3UfWYFkn9F_3Ptkf1Y_pmZBcK+B15JArZPrB0hw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> I'm not sure whether there's a way to fix this that doesn't break other
> cases. We could retrieve the pg_database.datcollate string from the
> remote, but that doesn't necessarily match up with any collation name
> we know about locally. One pretty common failure mode would be that
> the datcollate string isn't a canonical spelling (eg, "en_US.UTF-8"
> where the name we know about is "en_US.utf8"). In general, datcollate
> is handled through other code paths than collation names, so it might
> easily be that it doesn't match anything in the remote's pg_collation
> catalog either :-(.
>
This is where we got stuck as well (+David who did a lot of digging on this
issue). Hence submitting the discovery without our half-baked patch.
We had difficulty finding the place in the code were LC_COLLATE gets
recombobulated into a recognized collation.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-09-20 16:20:31 | Re: Varying results when using merge joins over postgres_fdw vs hash joins |
| Previous Message | Tom Lane | 2017-09-20 16:18:23 | Re: pgsql: Add basic TAP test setup for pg_upgrade |