On 2015-08-27 11:31:44 -0400, Tom Lane wrote:
> Needs a bit of copy-editing in places, but +1 overall.
Heres a slightly expanded version of this. I tried to do some of the
copy-editing, but I'm sure a look from a native speaker won't hurt.
Greetings,
Andres Freund
diff --git a/doc/src/sgml/sourc
On Wed, Aug 12, 2015 at 10:40:53PM +0200, Andres Freund wrote:
> You might argue that it's nothing we have touched frequently. And you're
> right. But I think that's a mistake. We spend far too much time in the
> various pieces of code dissembling tuples, and I think at some point
> somebody really
On Wed, Aug 12, 2015 at 04:47:55PM -0400, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 4:34 PM, Heikki Linnakangas wrote:
> > Andres didn't mention how big the performance benefit he saw with pgbench
> > was, but I bet it was barely distinguishible from noise. But that's OK. In
> > fact, there's n
On Wed, Aug 5, 2015 at 03:46:36PM +0200, Andres Freund wrote:
> On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> > We might later want to change some of the harder to maintain macros to
> > inline functions, but that seems better done separately.
>
> Here's a conversion for fastgetattr() and
On Thu, Aug 27, 2015 at 11:31:44AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > As Noah I think it'd be good if we, over time, started to document a few
> > more things one currently have to pick up over time. I'm wondering
> > whether these should be subsections under a new sect1 ('Code Str
Tom Lane wrote:
> It strikes me that the information in backend/utils/mmgr/README would be
> a good candidate to move into the Internals SGML, too. Almost none of
> that is "stuff you only care about when reading utils/mmgr/".
Completely agreed.
--
Álvaro Herrerahttp://www.2ndQ
Robert Haas writes:
> Yeah. I bet there's a lot more useful stuff we could include also,
> but everything Andres mentioned is certainly good to put in there.
> Alternatively, some of this stuff could go into a README file instead
> of the documentation, but I think we've been leaning toward
> doc
On Thu, Aug 27, 2015 at 4:31 PM, Tom Lane wrote:
>> That's not yet perfect, but shows what I'm thinking of. Comments?
>
> Needs a bit of copy-editing in places, but +1 overall.
Yeah. I bet there's a lot more useful stuff we could include also,
but everything Andres mentioned is certainly good to
Andres Freund writes:
> As Noah I think it'd be good if we, over time, started to document a few
> more things one currently have to pick up over time. I'm wondering
> whether these should be subsections under a new sect1 ('Code Structure'?
> Don't like that much), or all independent sect1s.
"Str
On 2015-08-16 05:58:17 +0200, Andres Freund wrote:
> On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
> > The policy would then be
> > (already is?) to wrap in "#ifdef FRONTEND" any inline function that uses a
> > backend symbol. When a header is dedicated to such functions, we might
> > avoid
> >
On Mon, Aug 17, 2015 at 12:06:42PM +0200, Andres Freund wrote:
> On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
> I'd love to make it a #warning intead of an error, but unfortunately
> that's not standard C :(
Okay.
> > Other than that benefit, making headers #error-on-FRONTEND mostly lets
> > u
On Mon, Aug 17, 2015 at 12:36 PM, Andres Freund wrote:
> On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
>> - The possibility that may repeatedly break #define FRONTEND
>> compilation when we add static inline functions, where instead adding
>> macros would not have caused breakage, thus resultin
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
> As far as I can see, the anticipated benefits of what we're doing here are:
>
> - Get a cleaner separation of frontend and backend headers (this could
> also be done independently of STATIC_IF_INLINE, but removing
> STATIC_IF_INLINE increases the
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
> - The possibility that may repeatedly break #define FRONTEND
> compilation when we add static inline functions, where instead adding
> macros would not have caused breakage, thus resulting in continual
> tinkering with the header files.
Again, tha
On Sat, Aug 15, 2015 at 8:03 PM, Andres Freund wrote:
>> That gave me new respect for STATIC_IF_INLINE. While it does add tedious
>> work
>> to the task of introducing a new batch of inline functions, the work is
>> completely mechanical. Anyone can write it; anyone can review it; there's
>> o
On 2015-08-17 15:51:33 +0100, Greg Stark wrote:
> But I'm not clear from the discussion exactly which compilers we're
> thinking of ruling out.
None.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On Wed, Jul 1, 2015 at 5:14 PM, Andres Freund wrote:
> During the 9.5 cycle, and earlier, the topic of increasing our minimum
> bar for compilers came up a bunch of times. Specifically whether we
> still should continue to use C90 as a baseline.
>
> I think the time has come to rely at least on so
On Wed, Jul 1, 2015 at 11:14 AM, Andres Freund wrote:
> Hi,
>
> During the 9.5 cycle, and earlier, the topic of increasing our minimum
> bar for compilers came up a bunch of times. Specifically whether we
> still should continue to use C90 as a baseline.
Minor question: is there any value to keep
On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
> As we see from the patches' need to add #include statements to .c files and
> from Robert's report of a broken EDB build, this change creates work for
> maintainers of non-core code, both backend code (modules) and frontend code
> (undocumented, but
Andres Freund writes:
> On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
>> Solaris Studio 12.3 (newest version as of Oct 2014) still does that
>> when optimization is disabled, and I place sufficient value on keeping
>> inlining enabled for such a new compiler.
> Ah, that's cool. I was wondering
On Fri, Aug 14, 2015 at 08:40:13PM +0200, Andres Freund wrote:
> > > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > > > > + * lockdefs.h
> > > > > + * Frontend exposed parts of postgres' low level lock mechanism
> I actually think the split came out to work far better than I'd
> anti
On Sun, Aug 16, 2015 at 05:58:17AM +0200, Andres Freund wrote:
> On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
> > On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
> > > On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
> > > > $ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
> > >
On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
> On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
> > On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
> > > $ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
> > > pg_resetxlog.o: In function `fastgetattr':
> > > /data/nmisch/src/pg/p
On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
> On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
> > $ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
> > pg_resetxlog.o: In function `fastgetattr':
> > /data/nmisch/src/pg/postgresql/src/bin/pg_resetxlog/../../../src/include/access
On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
> Atomics were a miner's canary for pademelon's trouble with post-de6fd1c
> inlining. Expect pademelon to break whenever a frontend-included file gains
> an inline function that calls a backend function. Atomics were the initial
> examples, but this
Andres Freund writes:
> On August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch wrote:
>> That gave me new respect for STATIC_IF_INLINE. While it does add
>> tedious work to the task of introducing a new batch of inline
>> functions, the work is completely mechanical. Anyone can write it;
>> anyone
On August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch wrote:
>On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
>> On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
>> > Here's a conversion for fastgetattr() and heap_getattr().
>
>> In my opinion this drastically increases readability
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
> On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
> > Here's a conversion for fastgetattr() and heap_getattr().
> In my opinion this drastically increases readability and thus should be
> applied.
Atomics were a miner's canary for
On Fri, Aug 14, 2015 at 2:40 PM, Andres Freund wrote:
> To pick up on the general discussion and on the points you made here:
>
> I actually think the split came out to work far better than I'd
> anticipated. Having a slimmed-down version of lock.h for code that just
> needs to declare/pass lockmo
Hi,
On 2015-08-06 12:43:06 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
>
> > > Ah, but that's because you cheated and didn't remove the include from
> > > namespace.h ...
> >
> > Well, it's not included from frontend code, so I didn
On Wed, Aug 12, 2015 at 4:34 PM, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise. But that's OK. In
> fact, there's no reason to believe this would make any difference to
> performance.
On 2015-08-12 23:34:38 +0300, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise.
I think it was discernible (I played around with changing unrelated code
trying to exclude unrelated layout
On 2015-08-12 16:25:17 -0400, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
> > The only actual separate patch since then (fastgetattr as inline
> > function) was posted 2015-08-05 and I yesterday suggested to push it
> > today. And it's just replacing two existing mac
On Wed, Aug 12, 2015 at 1:34 PM, Heikki Linnakangas wrote:
> Andres didn't mention how big the performance benefit he saw with pgbench
> was, but I bet it was barely distinguishible from noise. But that's OK. In
> fact, there's no reason to believe this would make any difference to
> performance.
On 08/12/2015 11:25 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
The only actual separate patch since then (fastgetattr as inline
function) was posted 2015-08-05 and I yesterday suggested to push it
today. And it's just replacing two existing macros by inline fun
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund wrote:
> The only actual separate patch since then (fastgetattr as inline
> function) was posted 2015-08-05 and I yesterday suggested to push it
> today. And it's just replacing two existing macros by inline functions.
I'm a little concerned about th
On 2015-08-12 13:00:25 -0400, Robert Haas wrote:
> On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch wrote:
> >> In my opinion this drastically increases readability and thus should be
> >> applied. Will do so sometime tomorrow unless there's protest.
> >
> > -1 to introducing more inline functions bef
On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch wrote:
>> In my opinion this drastically increases readability and thus should be
>> applied. Will do so sometime tomorrow unless there's protest.
>
> -1 to introducing more inline functions before committable code replaces what
> you've already pushed
On 2015-08-08 02:30:44 -0400, Noah Misch wrote:
> On Sat, Aug 08, 2015 at 02:30:47AM +0200, Andres Freund wrote:
> > On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
> > > I agree that lock.h offers little to frontend code. Headers that the
> > > lockdefs.h patch made usable in the frontend, partic
On 2015-08-11 22:34:40 -0400, Noah Misch wrote:
> On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
> > On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
> > > On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> > > > We might later want to change some of the harder to maintain macro
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
> On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
> > On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> > > We might later want to change some of the harder to maintain macros to
> > > inline functions, but that seems better done
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
> On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> > We might later want to change some of the harder to maintain macros to
> > inline functions, but that seems better done separately.
>
> Here's a conversion for fastgetattr() and heap_getattr
On Sat, Aug 08, 2015 at 02:30:47AM +0200, Andres Freund wrote:
> On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
> > I agree that lock.h offers little to frontend code. Headers that the
> > lockdefs.h patch made usable in the frontend, particularly genam.h and
> > hash.h,
> > are no better.
>
>
Andres Freund writes:
> On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
>> On another note, I'm perplexed by the high speed commits from this thread.
>> Commit de6fd1c landed just 191 minutes after you posted the first version of
>> its patch. Now lockdefs.h is committed, right in the middle of d
On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
> I agree that lock.h offers little to frontend code. Headers that the
> lockdefs.h patch made usable in the frontend, particularly genam.h and hash.h,
> are no better.
It's not that simple. Those two, and tuptoaster.h, are actually somewhat
validly
On Fri, Aug 07, 2015 at 03:18:06PM +0200, Andres Freund wrote:
> On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
> > On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> > > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > > > Andres Freund wrote:
> > > > > @@ -0,0 +1,56 @@
> > >
Andres Freund wrote:
> You re-added the #ifndef FRONTEND there in a9baeb361d635 referencing a
> buildfarm failure. It seems to originally have been added in
> 7507b193bc54 referencing buildfarm member warthog which unfortunately
> doesn't exist anymore...
FWIW we make a point of not reusing build
On 2015-08-07 14:48:43 -0400, Tom Lane wrote:
> Indeed, but the buildfarm results say that the set of such platforms is
> nearly empty. It's very likely that a lot of third-party authors won't
> ever care if their code doesn't build on such platforms; certainly not
> nearly as much as they'll care
Andres Freund writes:
> On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
>> Eventually I think we're going to have to spend some effort on making a
>> clearer separation between "front end safe" and "not front end safe"
>> header files. Until we do that, though, adding these #error directives
>> may
On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Well, I just work here, but it seems silly to me to reorgnize the
> > headers so that you can include fewer definitions where necessary, but
> > then not revise the existing headers to use the slimmed-down versions
> > where p
Robert Haas writes:
> Well, I just work here, but it seems silly to me to reorgnize the
> headers so that you can include fewer definitions where necessary, but
> then not revise the existing headers to use the slimmed-down versions
> where possible. Yeah, somebody might have to adjust their #inc
On Fri, Aug 7, 2015 at 2:27 PM, Andres Freund wrote:
> On 2015-08-07 14:15:58 -0400, Robert Haas wrote:
>> On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund wrote:
>> > On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
>> >> It may not be included from any IN CORE frontend code, but that is not
>> >>
On 2015-08-07 14:15:58 -0400, Robert Haas wrote:
> On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund wrote:
> > On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
> >> It may not be included from any IN CORE frontend code, but that is not
> >> the same thing as saying it's not included from any frontend
On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund wrote:
> On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
>> It may not be included from any IN CORE frontend code, but that is not
>> the same thing as saying it's not included from any frontend code at
>> all. For example, EDB has code that includes
On 2015-08-07 19:11:52 +0200, Andres Freund wrote:
> I think the likelihood of actually breaking correct working extension
> code that uses namespace.h that'd be broken if we removed lock.h from
> namespace.h is an order of magnitude bigger than the possible impact on
> frontend code.
Same with dr
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
> It may not be included from any IN CORE frontend code, but that is not
> the same thing as saying it's not included from any frontend code at
> all. For example, EDB has code that includes namespace.h in frontend
> code. That compiled before this
On Thu, Aug 6, 2015 at 11:34 AM, Andres Freund wrote:
> On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
>> Andres Freund wrote:
>>
>> > I had to split of three things: LOCKMASK, the individual lock levels and
>> > xl_standby_lock to be able to prohibit lock.h to be included by frontend
>> > co
On Fri, Aug 07, 2015 at 03:20:00PM +0200, Andres Freund wrote:
> Unless you have a better idea I'll now move the detection of that case
> to aix.h.
Nope, that seemed right to me.
> I rather liked being able to emit a warning about disabling inlines
> *once* during configuration, but it's also pro
Andres Freund wrote:
> > lock.h includes lwlock.h only for the benefit of the three
> > LockHashPartition*
> > macros. Those macros are pieces of the lock.c implementation that cross
> > into
> > proc.c, not pieces of the lock.c public API.
>
> I argued that way as well upthread. But I do thin
On 2015-08-05 21:39:26 -0400, Noah Misch wrote:
> On Wed, Aug 05, 2015 at 10:32:48AM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> > > couple years now? My willingness to expend effort for that is rather
> > > limit
On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
> On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > > Andres Freund wrote:
> > > > @@ -0,0 +1,56 @@
> > > > +/*---
On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > @@ -0,0 +1,56 @@
> > > +/*-
> > > + *
> > > + * lockdefs.h
> > > + * F
Andres Freund wrote:
> On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > Ah, but that's because you cheated and didn't remove the include from
> > namespace.h ...
>
> Well, it's not included from frontend code, so I didn't see the need?
> Going through all the backend code and replacing loc
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > I had to split of three things: LOCKMASK, the individual lock levels and
> > xl_standby_lock to be able to prohibit lock.h to be included by frontend
> > code. lockdefs.h works for me, counter proposals?
> >
> > Ther
Andres Freund wrote:
> I had to split of three things: LOCKMASK, the individual lock levels and
> xl_standby_lock to be able to prohibit lock.h to be included by frontend
> code. lockdefs.h works for me, counter proposals?
>
> There weren't any places that needed additional lock.h includes.
Ah,
On 2015-08-06 12:05:24 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > >> One approach is to avoid including lwlock.h/slot.h in frontend
> > > >> code. That'll require some minor surgery and adding a couple inc
Andres Freund wrote:
> On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > >> One approach is to avoid including lwlock.h/slot.h in frontend
> > >> code. That'll require some minor surgery and adding a couple includes,
> > >> but it doesn't look that bad.
> >
> > > Patch d
On Thu, Aug 6, 2015 at 10:31 AM, Andres Freund wrote:
> On 2015-08-06 10:29:39 -0400, Robert Haas wrote:
>> On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund wrote:
>> > It really doesn't. It's just fallout from indirectly including lwlock.h
>> > which includes an atomic variable. The include path le
On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> One approach is to avoid including lwlock.h/slot.h in frontend
> >> code. That'll require some minor surgery and adding a couple includes,
> >> but it doesn't look that bad.
>
> > Patch doing that attached.
>
> This seems
On 2015-08-06 10:29:39 -0400, Robert Haas wrote:
> On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund wrote:
> > It really doesn't. It's just fallout from indirectly including lwlock.h
> > which includes an atomic variable. The include path leading to it is
> >
> > In file included from
> > /home/andr
On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund wrote:
> It really doesn't. It's just fallout from indirectly including lwlock.h
> which includes an atomic variable. The include path leading to it is
>
> In file included from
> /home/andres/src/postgresql/src/include/storage/lwlock.h:19:0,
>
Andres Freund writes:
>> One approach is to avoid including lwlock.h/slot.h in frontend
>> code. That'll require some minor surgery and adding a couple includes,
>> but it doesn't look that bad.
> Patch doing that attached.
This seems kinda messy. Looking at the contents of lock.h, it seems lik
On 2015-08-05 23:18:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > ... I'm going to reshuffle things in that direction tomorrow. I'll
> > wait for other fallout first though. So far only gcc, xlc and clang (via
> > gcc frontend) have run...
>
> In the department of "other fallout", pademel
Andres Freund writes:
> ... I'm going to reshuffle things in that direction tomorrow. I'll
> wait for other fallout first though. So far only gcc, xlc and clang (via
> gcc frontend) have run...
In the department of "other fallout", pademelon is not happy:
cc -Ae -g +O0 -Wp,-H16384 -I../../../src
On Wed, Aug 05, 2015 at 10:32:48AM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> > couple years now? My willingness to expend effort for that is rather
> > limited.
>
> Well, there's one in the buildfarm. We don't gen
On 2015-08-05 17:19:05 +0200, Andres Freund wrote:
> On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Ok, lets' do it that way then. It seems the easiest way to test for this
> > > is to use something like
> >
> > > # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-
On 2015-08-05 11:23:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm ok with that too, although I do like the warning at configure
> > time. I'd go with the template approach due to that, but I don't feel
> > strongly about it.
>
> Meh. I did *not* like the way you proposed doing that:
Andres Freund writes:
> I'm ok with that too, although I do like the warning at configure
> time. I'd go with the template approach due to that, but I don't feel
> strongly about it.
Meh. I did *not* like the way you proposed doing that: it looked far too
dependent on autoconf internals (the kin
On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Ok, lets' do it that way then. It seems the easiest way to test for this
> > is to use something like
>
> > # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> > # expansions of ginCompareItemPointers() "
Andres Freund writes:
> Ok, lets' do it that way then. It seems the easiest way to test for this
> is to use something like
> # "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> # expansions of ginCompareItemPointers() "long long" arithmetic. To
> # take advantage of inlining,
On 2015-08-05 10:32:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> > couple years now? My willingness to expend effort for that is rather
> > limited.
>
> Well, there's one in the buildfarm.
Oh nice. That's new. I s
Andres Freund writes:
> Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
> couple years now? My willingness to expend effort for that is rather
> limited.
Well, there's one in the buildfarm. We don't generally turn off
buildfarm critters just because the underlying OS is o
On 2015-08-05 10:23:31 -0400, Tom Lane wrote:
> Andres Freund writes:
> > How about moving that error check into into the aix template file and
> > erroring out there? Since this is master I think it's perfectly fine to
> > refuse to work with the buggy unsupported 32 bit compiler. The argument
>
Andres Freund writes:
> On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
>> Hmm. I notice that this removes Noah's hack from commit c53f73879f552a3c.
>> Do we care about breaking old versions of xlc, and if so, how are we going
>> to fix that? (I assume it should be possible to override AC_C_INLINE
On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
> >> So unless somebody protests I'm going to prepare (and commit after
> >> posting) a patch to rip out the bits of code that currently depend on
> >> PG_USE_INLINE.
>
> >
Andres Freund writes:
> On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
>> So unless somebody protests I'm going to prepare (and commit after
>> posting) a patch to rip out the bits of code that currently depend on
>> PG_USE_INLINE.
> Here's that patch. I only removed code dependant on PG_USE_
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
> We might later want to change some of the harder to maintain macros to
> inline functions, but that seems better done separately.
Here's a conversion for fastgetattr() and heap_getattr(). Not only is
the resulting code significantly more readabl
On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
> So unless somebody protests I'm going to prepare (and commit after
> posting) a patch to rip out the bits of code that currently depend on
> PG_USE_INLINE.
Here's that patch. I only removed code dependant on PG_USE_INLINE. We
might later want to
On 2015-08-04 16:55:12 -0400, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund wrote:
> > On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
> >> I'm not sure that there's any great urgency about changing the instances
> >> that exist now; the real point of this discussion is that we
On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund wrote:
> On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
>> I'm not sure that there's any great urgency about changing the instances
>> that exist now; the real point of this discussion is that we will allow
>> new code to use static inlines in headers.
On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
> I'm not sure that there's any great urgency about changing the instances
> that exist now; the real point of this discussion is that we will allow
> new code to use static inlines in headers.
I agree that we don't have to (and probably shouldn't) mak
Andres Freund writes:
> On 2015-08-04 15:20:14 -0400, Robert Haas wrote:
>> OK, so do we want to rip out all instances of the static inline dance
>> in favor of more straightforward coding? Do we then shut pandemelon
>> and any other affected buildfarm members down as unsupported, or what?
> I t
On 2015-08-04 15:20:14 -0400, Robert Haas wrote:
> OK, so do we want to rip out all instances of the static inline dance
> in favor of more straightforward coding? Do we then shut pandemelon
> and any other affected buildfarm members down as unsupported, or what?
I think all that happens is that
On Thu, Jul 2, 2015 at 12:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> So far this thread is all about the costs of desupporting compilers
>> that don't have these features, and you're making a good argument
>> (that I think we all agree with) that the cost is small. But you
>> haven't really
Robert Haas writes:
> So far this thread is all about the costs of desupporting compilers
> that don't have these features, and you're making a good argument
> (that I think we all agree with) that the cost is small. But you
> haven't really said what the benefits are.
I made the same remark wit
On 2015-07-02 11:46:25 -0400, Robert Haas wrote:
> In the case of static inline, the main problem with the status quo
> AFAICS is that you have to do a little dance any time you'd otherwise
> use a static inline function (for those following along at home, "git
> grep INCLUDE_DEFINITIONS src/includ
On Wed, Jul 1, 2015 at 6:24 PM, Andres Freund wrote:
> On 2015-07-02 00:15:14 +0200, Andres Freund wrote:
>> animal OS compiler inline quiet inline
>>varargs
>
>> brolga cygwin gcc-4.3 yy
>
> 4.3 obviously supports
On 2015-07-01 19:05:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Since, buildfarm/quiet inline test issues aside, pademelon is the only
> > animal not supporting inlines and varargs, I think we should just go
> > ahead and start to use both.
>
> I'm good with using inlines, since as I po
Andres Freund writes:
> Since, buildfarm/quiet inline test issues aside, pademelon is the only
> animal not supporting inlines and varargs, I think we should just go
> ahead and start to use both.
I'm good with using inlines, since as I pointed out upthread, that won't
actually break anything. I
On 2015-07-02 00:15:14 +0200, Andres Freund wrote:
> animal OS compiler inline quiet inline
> varargs
> brolga cygwin gcc-4.3 yy
4.3 obviously supports varargs. Human error.
> pademelonHP-UX 10.2 HP C Comp
1 - 100 of 109 matches
Mail list logo
