Horton

Re: [PATCH 04/16] Add embedded list interface (header only)

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Peter Geoghegan <peter@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-06-25T15:34:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't waste the last segment of each 4GB logical log file.

  2. Stamp HEAD as 9.3devel.

  3. Wake WALSender to reduce data loss at failover for async commit.

  4. Make the visibility map crash-safe.

On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
> >> This is nonsense.  There are at least three buildfarm machines running
> >> compilers that do not "pretend to be gcc" (at least, configure
> >> recognizes them as not gcc) and are not MSVC either.
> > 
> > Should there be no other trick - I think there is though - we could just
> > specify -W2177 as an alternative parameter to test in the 'quiet static
> > inline' test.
> What is that, an MSVC switch?  If so it's rather irrelevant to non-MSVC
> compilers.
HP-UX/aCC, the only compiler in the buildfarm I found that seems to fall short 
in the "quiet inline" test.

MSVC seems to work fine with in supported versions, USE_INLINE is defined 
these days.

> > I definitely do not want to bar any sensible compiler from compiling
> > postgres but the keyword here is 'sensible'. If it requires some modest
> > force/trickery to behave sensible, thats ok, but if we need to ship
> > around huge unreadable crufty macros just to support them I don't find
> > it ok.
> So you propose to define any compiler that strictly implements C99 as
> not sensible and not one that will be able to compile Postgres?  I do
> not think that's acceptable.  I have no problem with producing better
> code on gcc than elsewhere (as we already do), but being flat out broken
> for compilers that don't match gcc's interpretation of "inline" is not
> good enough.
I propose to treat any compiler which has no way to get to equivalent 
behaviour as not sensible. Yes. I don't think there really are many of those 
around. As you pointed out there is only one compiler in the buildfarm with 
problems and I think those can be worked around (can't test it yet though, the 
only HP-UX I could get my hands on quickly is at 11.11...).

Greetings,

Andres

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services