| 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:13:57 |
| Message-ID: | 3884.1538410437@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 11:58:51 -0400, Tom Lane wrote:
>> Oooh ... apparently, on that platform, memcmp() is willing to produce
>> INT_MIN in some cases. That's not a safe value for a sort comparator
>> to produce --- we explicitly say that somewhere, IIRC.
> Hm, that'd be pretty painful - memcmp() isn't guaranteed to return
> anything smaller. And we use memcmp in a fair number of comparators.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-10-01 16:26:56 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |
| Previous Message | Andres Freund | 2018-10-01 16:04:55 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |