Re: Odd 9.4, 9.3 buildfarm failure on s390x
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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:13:57Z
Lists: pgsql-hackers
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. regards, tom lane
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