Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails

Jiří Fejfar <jurafejfar@gmail.com>

From: Jiří Fejfar <jurafejfar@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-08-19T05:39:36Z
Lists: pgsql-bugs, pgsql-hackers
On 17.08.2020 17:26, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> Joining two identical tables placed on separate DBs with different collation
>> accessed through postgres_fdw failed when joined with merge join. Some
>> records are missing (7 vs. 16 rows in example) in output. See this snippet
>> https://gitlab.com/-/snippets/2004522 (or code pasted below) for psql script
>> reproducing error also with expected output (working fine on alpine linux).
> So I think what is happening here is that postgres_fdw's version of
> IMPORT FOREIGN SCHEMA translates "COLLATE default" on the remote
> server to "COLLATE default" on the local one, which of course is
> a big fail if the defaults don't match.  That allows the local
> planner to believe that remote ORDER BYs on the two foreign tables
> will give compatible results, causing the merge join to not work
> very well at all.

I am just wondering: if it is bug in IMPORT FOREIGN SCHEMA, how it is 
possible the bug is not present [1] when provided psql script [2] is run 
on Alpine Linux? I suppose, both Debian and Alpine has the same IMPORT 
FOREIGN SCHEMA behavior (both has PG12.4). But differs in glibc vs. musl 
libc. Is it possible, there is also something differing in those 
libraries with respect to cs.CZ-UTF8?

Best regards, Jiří.

[1] https://gitlab.com/-/snippets/2004522#note_396751634

[2] https://gitlab.com/-/snippets/2004522




Commits

  1. Doc: extend warnings about collation-mismatch hazards in postgres_fdw.

  2. Add support for asynchronous execution.

  3. Suppress unnecessary RelabelType nodes in yet more cases.