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

From Joe Conway
Subject Re: Inconsistent results with libc sorting on Windows
Date
Msg-id 94ee6f5f-4726-6b1d-b50e-b4e178663f45@joeconway.com
Whole thread Raw
In response to Re: Inconsistent results with libc sorting on Windows  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Inconsistent results with libc sorting on Windows
List pgsql-hackers
On 6/7/23 07:58, Daniel Verite wrote:
>     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).


Wow, that sounds pretty horrid

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)
Next
From: Joe Conway
Date:
Subject: Re: Let's make PostgreSQL multi-threaded