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: | Whole Thread | Raw Message | 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
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) |