| From: | "Daniel Westermann (DWE)" <daniel(dot)westermann(at)dbi-services(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Wrong results with postgres_fdw and merge anti join from RHEL 7.9 to RHEL 8.7 |
| Date: | 2023-04-05 19:20:21 |
| Message-ID: | GV0P278MB041930B2E5FE2DFEC77FE36FD2909@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
>Yeah, doesn't look like you've made any configuration mistakes.
>So either the two OSes sort differently, or there's index corruption
>causing the indexscan to give bogus output.
We did a rebuild of the indexes and also vacuum full, just to be sure. Did not change anything.
>The sample data you showed seemed to only involve numeric-ish strings,
>which would be highly unlikely to change sort order across locale
>updates. But maybe there are weirder entries elsewhere in the column?
I can probably provide a dump, but I've to ask. Would that help?
>Anyway, the first thing I'd try is reindexing both tables --- doesn't
>look like they're large enough to make that painful. If that doesn't
>fix it you must have a collation difference. (Asking both systems
>for a sorted dump of their cprd columns could help confirm that.)
>You could probably hack around that, if an OS update isn't feasible,
>by labelling the foreign table's column with some collation you aren't
>using anywhere else in the local database.
I'll try do that tomorrow.
Thanks
Daniel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Mlodgenski | 2023-04-05 19:46:43 | Re: Wrong results with postgres_fdw and merge anti join from RHEL 7.9 to RHEL 8.7 |
| Previous Message | Tom Lane | 2023-04-05 19:04:56 | Re: Wrong results with postgres_fdw and merge anti join from RHEL 7.9 to RHEL 8.7 |