Horton

Re: master make check fails on Solaris 10

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marina Polyakova <m.polyakova@postgrespro.ru>, "Victor Wagner *EXTERN*" <vitus@wagner.pp.ru>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2018-01-18T18:24:36Z
Lists: pgsql-hackers 
On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sure.  Part of the equation here is that (IMO anyway) int128 isn't
> sufficiently performance-critical to us to justify putting enormous
> amounts of work into trying to make it go on non-mainstream platforms.
> It's possible that that could change in future ... but if part of the
> cost is notational changes that make it harder and more bug-prone
> to use int128 at all, then I daresay int128 will never become that
> performance-critical, because it would always remain a niche thing.

That's possible.  On the other hand, we lived for many years with
painful workarounds for systems without working 64-bit integers, and
those eventually became mainstream enough that we made them mandatory
- and then ripped out some of the notational changes that we'd
introduced to cope with platforms that didn't support them.  So, the
same thing might happen here, whatever we decide about this.  Then
again, 64 bit counters are already so large that it's hard to imagine
ever having one overflow, so perhaps 128-bit values will never catch
on in quite the same way.  On the third hand, 640kB ought to be enough
for anybody.

Anyway, that's really an academic debate.  My real point is: I do not
think we should reject out of hand the idea that a patch introducing
some new notation to deal with this might be acceptable.  I am not
volunteering to write such a patch, and anyone who tries should be
aware that there is a chance that it will be rejected on grounds of
ugliness.  However, if they decide to try anyway, we should read the
patch and see how ugly it really is.  Maybe it's not that bad.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Extend configure's __int128 test to check for a known gcc bug.

  2. Reorder C includes

  3. Ability to advance replication slots

  4. doc: add JSON acronym

  5. Expression evaluation based aggregate transition invocation.

  6. Change some bogus PageGetLSN calls to BufferGetLSNAtomic

  7. Prevent int128 from requiring more than MAXALIGN alignment.

  8. Rearrange c.h to create a "compiler characteristics" section.

  9. Make OWNER TO subcommand mention consistent