Re: Inconsistent results with libc sorting on Windows

From: Joe Conway <mail(at)joeconway(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inconsistent results with libc sorting on Windows
Date: 2023-06-07 12:42:13
Message-ID: 94ee6f5f-4726-6b1d-b50e-b4e178663f45@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

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