On Fri, Jun 27, 2014 at 07:51:32PM +0200, Andres Freund wrote:
> On 2014-06-27 13:12:31 -0400, Robert Haas wrote:
> > I don't personally object to dropping Alpha, but when this was
> > discussed back in October, Stefan did:
> >
> > http://www.postgresql.org/message-id/52616373.10...@kaltenbrunner.
On 06/27/2014 08:26 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-06-27 13:12:31 -0400, Robert Haas wrote:
>>> I don't personally object to dropping Alpha, but when this was
>>> discussed back in October, Stefan did:
>>>
>>> http://www.postgresql.org/message-id/52616373.10...@kaltenbrunne
Andres Freund writes:
> On 2014-06-27 13:12:31 -0400, Robert Haas wrote:
>> I don't personally object to dropping Alpha, but when this was
>> discussed back in October, Stefan did:
>>
>> http://www.postgresql.org/message-id/52616373.10...@kaltenbrunner.cc
As an ex-packager I do not believe the a
On 2014-06-27 13:12:31 -0400, Robert Haas wrote:
> I have noticed that most PostgreSQL committers seem for format their
> commit messages so that paragraphs are separated by a blank line, but
> you seem not to do that. I find that less readable.
I'll change that.
> > Since there seems to be (una
On Fri, Jun 27, 2014 at 9:59 AM, Andres Freund wrote:
> On 2014-06-24 10:22:08 -0700, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
>> >> If a change has the potential to make some architectures give wrong
>> >> answers only at odd times, that's a d
On 2014-06-24 10:22:08 -0700, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> >> If a change has the potential to make some architectures give wrong
> >> answers only at odd times, that's a different kind of problem. For
> >> that reason, actively bre
On 2014-06-24 10:22:08 -0700, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> >> If a change has the potential to make some architectures give wrong
> >> answers only at odd times, that's a different kind of problem. For
> >> that reason, actively bre
On Tue, Jun 24, 2014 at 07:09:08PM +0200, Andres Freund wrote:
> On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> > What I'm hearing is that you see two options, (1) personally authoring
> > e.g. sparcv8 code or (2) purging the source tree of sparcv8 code before
> > submitting the patch that would
Andres Freund writes:
> On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
>> If a change has the potential to make some architectures give wrong
>> answers only at odd times, that's a different kind of problem. For
>> that reason, actively breaking Alpha is a good thing.
> Not sure what you mean w
On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote:
> > On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> > > Telling people that
> > > they can't have even the most minimal platform support code in
> > > PostgreSQL unless they're willin
On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote:
> On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> > Telling people that
> > they can't have even the most minimal platform support code in
> > PostgreSQL unless they're willing to contribute and maintain a BF VM
> > indefinitely is n
On 2014-06-23 12:46:11 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund
> wrote:
> >> > That we have support for platforms that we haven't even documented as
> >> > working (e.g. SuperH) or platforms that don't work in the realword
> >> > (m32r) means that that one has
On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund wrote:
>> > That we have support for platforms that we haven't even documented as
>> > working (e.g. SuperH) or platforms that don't work in the realword
>> > (m32r) means that that one has to think about and research so many more
>> > edge cases tha
On 2014-06-23 09:28:19 -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund
> > wrote:
> >> Since fetch-and-add is trivially implemented using CAS, there's not much
> >> need to distinguish between CAS and CAS + fetch_and_add. From my POV the
> >> rest
On 2014-06-23 12:08:08 -0400, Robert Haas wrote:
> > That we still have !PG_USE_INLINE support although all buildfarm animals
> > support it since 4c8aa8b (fixing acc) causes absurd constructs
> > (STATIC_IF_INLINE) and fugly macro usage making it harder to read
> > and modify code. I spend a good
Robert Haas writes:
> On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund
> wrote:
>> Since fetch-and-add is trivially implemented using CAS, there's not much
>> need to distinguish between CAS and CAS + fetch_and_add. From my POV the
>> restriction to just CAS/fetch_and_add isn't actually buying mu
On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund wrote:
>> This criterion has been proposed before, but I'm not sure I really
>> agree with it. If having code around that targets obscure platforms
>> is hindering the development of new features, then that's a reason to
>> get rid of it.
>
> I thin
On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> On Thu, Jun 19, 2014 at 10:43 AM, Merlin Moncure wrote:
> > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen
> > wrote:
> >> Let's not pretend to support platforms we have no practical way of
> >> verifying.
> >
> > This is key. The buildfarm
On Thu, Jun 19, 2014 at 10:43 AM, Merlin Moncure wrote:
> On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen
> wrote:
>> Let's not pretend to support platforms we have no practical way of
>> verifying.
>
> This is key. The buildfarm defines the set of platforms we support.
This criterion has b
On 2014-06-19 11:00:51 -0400, Alvaro Herrera wrote:
> Merlin Moncure wrote:
> > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen
> > wrote:
> > > Let's not pretend to support platforms we have no practical way of
> > > verifying.
> >
> > This is key. The buildfarm defines the set of platforms
Merlin Moncure wrote:
> On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen
> wrote:
> > Let's not pretend to support platforms we have no practical way of
> > verifying.
>
> This is key. The buildfarm defines the set of platforms we support.
This means that either Renesas should supply us with
On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen wrote:
> Let's not pretend to support platforms we have no practical way of
> verifying.
This is key. The buildfarm defines the set of platforms we support.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
At 2014-06-19 13:33:03 +0200, p...@2ndquadrant.com wrote:
>
> I think quite the opposite, it's better to say we don't support the
> obscure platform than saying that we do and have no active testing or
> proof that it indeed does and somebody finding the hard way that there
> are issues.
Yes, I st
On 18/06/14 17:15, Robert Haas wrote:
6) armv-v5
I think this is also a bit less dead than the other ones; Red Hat's
shows Bugzilla shows people filing bugs for platform-specific problems
as recently as January of 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=892378
Closed as WONTFIX :P.
On 2014-06-18 17:04:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund
> wrote:
> > There might be cases where that's true, but in the majority of cases
> > where the variable isn't highly contended it's just about the same. In
> > many cases the microcode will impleme
On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund wrote:
> There might be cases where that's true, but in the majority of cases
> where the variable isn't highly contended it's just about the same. In
> many cases the microcode will implement atomic ops using ll/sc
> operations internally anyway.
B
On 2014-06-18 11:15:15 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund wrote:
> > What happens is that gcc will do a syscall triggering the kernel to turn
> > of scheduling; perform the math and store the result; turn scheduling on
> > again. That way there cannot be a o
On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund wrote:
> But the concern is more whether 1 byte can actually be written
> without also writing neighbouring values. I.e. there's hardware out
> there that'll implement a 1byte store as reading 4 bytes, changing one
> of the bytes in a register, and th
Kevin Grittner wrote:
> Andres Freund wrote:
> The release of version n doesn't mean that version n-1 is no longer
> supported. As of today, this page:
>
> http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-138972.html
>
> says:
>
> > The Oracle Solaris 9 operating syst
On 17/06/14 22:32, Kevin Grittner wrote:
The release of version n doesn't mean that version n-1 is no longer
supported. As of today, this page:
http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-138972.html
says:
The Oracle Solaris 9 operating system is now in the Exte
On 2014-06-17 13:32:51 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> >> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund
> >> wrote:
>
> >>> 3) sparcv8: Last released model 1997.
> >>
> >> I seem to recall hearing about this in a custom
Andres Freund wrote:
> On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
>> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund
>> wrote:
>>> 3) sparcv8: Last released model 1997.
>>
>> I seem to recall hearing about this in a customer situation
>> relatively recently, so there may be a few of these
On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund wrote:
> > At this year developer's meeting we'd discussed the atomics abstraction
> > which is necessary for some future improvements. We'd concluded that a
> > overview over the hardware capabilitie
On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund wrote:
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supported platforms would
> be helpful. I've sta
On 2014-06-15 03:12:21 +0200, Andres Freund wrote:
> Hi,
>
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supported platforms would
> be helpful. I'v
Hi,
At this year developer's meeting we'd discussed the atomics abstraction
which is necessary for some future improvements. We'd concluded that a
overview over the hardware capabilities of the supported platforms would
be helpful. I've started with that at:
https://wiki.postgresql.org/wiki/Atomic
36 matches
Mail list logo
