Re: Odd 9.4, 9.3 buildfarm failure on s390x

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Mark Wong <mark(at)2ndQuadrant(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Andrew Dunstan <andrew(dot)dunstan(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Odd 9.4, 9.3 buildfarm failure on s390x
Date: 2018-10-01 16:50:16
Message-ID: 9873.1538412616@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
>> Yeah. So our choices are
>>
>> (1) Retain the current restriction on what sort comparators can
>> produce. Find all the places where memcmp's result is returned
>> directly, and fix them. (I wonder if strcmp has same issue.)
>>
>> (2) Drop the restriction. This'd require at least changing the
>> DESC correction, and maybe other things. I'm not sure what the
>> odds would be of finding everyplace we need to check.
>>
>> Neither one is sounding very pleasant, or maintainable.

> (2) seems more maintainable to me (or perhaps less unmaintainable). It's
> infrastructure, rather than every datatype + support out there...

I guess we could set up some testing infrastructure: hack int4cmp
and/or a couple other popular comparators so that they *always*
return INT_MIN, 0, or INT_MAX, and then see what falls over.

I'm fairly sure that btree, as well as the sort code proper,
has got an issue here.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matteo Beccati 2018-10-01 17:25:45 Re: [HACKERS] kqueue
Previous Message Andres Freund 2018-10-01 16:26:56 Re: Odd 9.4, 9.3 buildfarm failure on s390x