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:50:16Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.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
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