Re: Inconsistent results with libc sorting on Windows

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Inconsistent results with libc sorting on Windows
Дата
Msg-id 94ee6f5f-4726-6b1d-b50e-b4e178663f45@joeconway.com
обсуждение исходный текст
Ответ на Re: Inconsistent results with libc sorting on Windows  ("Daniel Verite" <daniel@manitou-mail.org>)
Ответы Re: Inconsistent results with libc sorting on Windows  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Let's make PostgreSQL multi-threaded