Re: Inconsistent results with libc sorting on Windows - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Inconsistent results with libc sorting on Windows
Date
Msg-id 23d2ec97-a25b-4d8f-bfce-8dac715eeea1@manitou-mail.org
Whole thread Raw
In response to Re: Inconsistent results with libc sorting on Windows  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Inconsistent results with libc sorting on Windows
List pgsql-hackers
    Thomas Munro wrote:

> > > Also, it does not occur at all if parallel scan is disabled.
> >
> > Could this be a clue that it is failing to be transitive?
>
> That vaguely rang a bell for me...  and then I remembered this thread:
>
> https://www.postgresql.org/message-id/flat/20191206063401.GB1629883%40rfd.leadboat.com

Thanks for the pointer, non-transitive comparisons seem a likely cause
indeed.

The parallel scan appears to imply some randomness in the sequence of
comparisons, which makes the problem more visible.
After changing the test to shuffle the rows before each sort,
non-parallel scans also produce outputs that differ, proving that
parallelism is not a root cause.

Running the test with all the libc collations with collencoding in
(-1,6) shows that the only ones not affected are C/POSIX/ucs_basic.
Otherwise the 569 other pre-created libc collations that can be used
with UTF-8 are affected, plus the default collation
(French_France.1252 in my case).


Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Nishant Sharma
Date:
Subject: Re: postgres_fdw: wrong results with self join + enable_nestloop off
Next
From: Tomas Vondra
Date:
Subject: Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)