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 →
-
Allow btree comparison functions to return INT_MIN.
- 6e63e0697516 9.3.25 landed
- 60cc2414beac 9.6.11 landed
- 26cc27541d92 9.4.20 landed
- 0dc6bf633a28 9.5.15 landed
- c87cb5f7a679 12.0 landed
- 67e7d4da72dc 11.0 landed
- 142cfd3cd82e 10.6 landed