Re: Odd 9.4, 9.3 buildfarm failure on s390x
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: Mark Wong <mark@2ndQuadrant.com>,
Andrew Gierth <andrew@tao11.riddles.org.uk>, pgsql-hackers@postgresql.org
Date: 2018-10-01T21:55:36Z
Lists: pgsql-hackers
On 10/01/2018 12:50 PM, Tom Lane wrote: > 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. > > I agree option 2 seems less unmaintainable. (Nice use of litotes there?) cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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