On 2014-01-21 10:20:35 -0500, Robert Haas wrote:
> On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp wrote:
> > On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund
> > wrote:
> >> The attached patches compile and make check successfully on linux x86,
> >> amd64 and msvc x86 and amd64. This time and upd
On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp wrote:
> On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund wrote:
>> The attached patches compile and make check successfully on linux x86,
>> amd64 and msvc x86 and amd64. This time and updated configure is
>> included. The majority of operations stil
On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund wrote:
> The attached patches compile and make check successfully on linux x86,
> amd64 and msvc x86 and amd64. This time and updated configure is
> included. The majority of operations still rely on CAS emulation.
Note that the atomics-generic-acc.h
On 2013-12-23 15:04:08 -0500, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund wrote:
> > On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
> >> Or does the warning
> >> mean code bloat (lots of useless copies of the inline function)?
> >
> > After thinking on that for a bit, yes tha
On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund wrote:
> On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > The only animal we have that doesn't support quiet inlines today is
>> > HP-UX/ac++, and I think - as in patch 1 in the series - we might be able
>> > to simply suppr
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The only animal we have that doesn't support quiet inlines today is
> > HP-UX/ac++, and I think - as in patch 1 in the series - we might be able
> > to simply suppress the warning there.
>
> Or just not worry about it, if i
On 2013-11-19 17:25:21 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 11:21:06PM +0100, Andres Freund wrote:
> > On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> > > On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > Do you mean inline? Or atomics? If the former no, if th
On Tue, Nov 19, 2013 at 11:21:06PM +0100, Andres Freund wrote:
> On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > > On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > > > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Fr
On 2013-11-19 17:16:56 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> > On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > > > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > >
On Tue, Nov 19, 2013 at 10:39:19PM +0100, Andres Freund wrote:
> On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > > > I don't have an informed opinion about requiring inlin
On 2013-11-19 16:37:32 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> > On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > > I don't have an informed opinion about requiring inline support
> > > > (although it would surely be nice).
> > >
> > > inli
On Tue, Nov 19, 2013 at 04:34:59PM +0100, Andres Freund wrote:
> On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > > I don't have an informed opinion about requiring inline support
> > > (although it would surely be nice).
> >
> > inline is C99, and we've generally resisted requiring C99 features.
On 2013-11-19 12:43:44 -0500, Robert Haas wrote:
> > * To be useful they usually will need to be placed in memory shared between
> > * processes or threads, most frequently by embedding them in structs. Be
> > * careful to align atomic variables to their own size!
>
> What does that mean exactl
On Tue, Nov 19, 2013 at 11:38 AM, Andres Freund wrote:
> /*-
> *
> * atomics.h
> *Generic atomic operations support.
> *
> * Hardware and compiler dependent functions for manipulating memory
> * atomically and de
On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The only animal we have that doesn't support quiet inlines today is
> > HP-UX/ac++, and I think - as in patch 1 in the series - we might be able
> > to simply suppress the warning there.
>
> Or just not worry about it, if i
Andres Freund writes:
> The only animal we have that doesn't support quiet inlines today is
> HP-UX/ac++, and I think - as in patch 1 in the series - we might be able
> to simply suppress the warning there.
Or just not worry about it, if it's only a warning? Or does the warning
mean code bloat (
On 2013-11-19 10:30:24 -0500, Tom Lane wrote:
> > I don't have an informed opinion about requiring inline support
> > (although it would surely be nice).
>
> inline is C99, and we've generally resisted requiring C99 features.
> Maybe it's time to move that goalpost, and maybe not.
But it's a part
On Tue, Nov 19, 2013 at 10:31 AM, Andres Freund wrote:
> On 2013-11-19 10:23:57 -0500, Robert Haas wrote:
>> > The only fundamental thing that I don't immediately see how we can
>> > support is the spinlock based memory barrier since that introduces a
>> > circularity (atomics need barrier, barrie
On 2013-11-19 10:23:57 -0500, Robert Haas wrote:
> > The only fundamental thing that I don't immediately see how we can
> > support is the spinlock based memory barrier since that introduces a
> > circularity (atomics need barrier, barrier needs spinlocks, spinlock
> > needs atomics).
>
> We've bee
Peter Eisentraut writes:
> On 11/19/13, 9:57 AM, Tom Lane wrote:
>> Hm. Now that I think about it, isn't Peter proposing to break systems
>> without working "inline" over here?
>> http://www.postgresql.org/message-id/1384257026.8059.5.ca...@vanquo.pezone.net
> No, that's about const, volatile, #
On Tue, Nov 19, 2013 at 10:26 AM, Andres Freund wrote:
> On 2013-11-19 09:12:42 -0500, Robert Haas wrote:
>> On point #1, I dunno. It looks like a lot of rearrangement to me, and
>> I'm not really sure what the final form of it is intended to be.
>
> Understandable. I am not that sure what parts
On 2013-11-19 09:12:42 -0500, Robert Haas wrote:
> On point #1, I dunno. It looks like a lot of rearrangement to me, and
> I'm not really sure what the final form of it is intended to be.
Understandable. I am not that sure what parts we want to rearange
either. We very well could leave barrier.h
On Tue, Nov 19, 2013 at 10:16 AM, Andres Freund wrote:
>> On the other hand, if the complaint is
>> "my hardware doesn't support 64-bit CAS", it's not reasonable to tell them
>> to buy a new server.
>
> Agreed. I've am even wondering about 32bit CAS since it's not actually
> that hard to emulate i
On Tue, Nov 19, 2013 at 9:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On point #2, I don't personally know of any systems that I care about
>> where inlining isn't supported. However, we've gone to quite a bit of
>> trouble relatively recently to keep things working for platforms where
>> th
On 2013-11-19 09:57:20 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On point #2, I don't personally know of any systems that I care about
> > where inlining isn't supported. However, we've gone to quite a bit of
> > trouble relatively recently to keep things working for platforms where
> > th
On 11/19/13, 9:57 AM, Tom Lane wrote:
> Hm. Now that I think about it, isn't Peter proposing to break systems
> without working "inline" over here?
> http://www.postgresql.org/message-id/1384257026.8059.5.ca...@vanquo.pezone.net
No, that's about const, volatile, #, and memcmp.
I don't have an in
Robert Haas writes:
> On point #2, I don't personally know of any systems that I care about
> where inlining isn't supported. However, we've gone to quite a bit of
> trouble relatively recently to keep things working for platforms where
> that is the case, so I feel the need for an obligatory dis
On Fri, Nov 15, 2013 at 3:04 PM, Andres Freund wrote:
> Questions:
> * What do you like/dislike about the API (storage/atomics.h)
> * decide whether it's ok to rely on inline functions or whether we need
> to provide out-of-line versions. I think we should just bite the
> bullet and require su
29 matches
Mail list logo
