Re: Odd 9.4, 9.3 buildfarm failure on s390x

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Wong <mark@2ndQuadrant.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Andrew Dunstan <andrew.dunstan@2ndQuadrant.com>, pgsql-hackers@postgresql.org
Date: 2018-10-01T16:26:56Z
Lists: pgsql-hackers
On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.

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

Greetings,

Andres Freund


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Allow btree comparison functions to return INT_MIN.