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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-06-25T15:11:23Z
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.

Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 22 June 2012 01:04, Tom Lane <tgl@sss.pgh.pa.us> 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.

> So those three don't have medium to high degrees of compatibility with GCC?

Uh, they all compile C, so perforce they have reasonable degrees of
compatibility with gcc.  That doesn't mean they implement gcc's
nonstandard extensions.

>> We ought to have more IMO, because software monocultures are
>> dangerous.  Of
>> those three, two pass the "quiet inline" test and one --- the newest of the three
>> if I guess correctly --- does not.  So it is not the case that
>> !USE_INLINE is dead code, even if you adopt the position that we don't
>> care about any compiler not represented in the buildfarm.

> I note that you said that it doesn't pass the "quiet inline" test, and
> not that it doesn't support inline functions.

What's your point?  If the compiler isn't implementing inline the same
way gcc does, we can't use the same inlining arrangements.  I will be
the first to agree that C99's definition of inline sucks, but that
doesn't mean we can assume that gcc's version is implemented everywhere.

			regards, tom lane