Re: Atomics hardware support table & supported architectures
От | Robert Haas |
---|---|
Тема | Re: Atomics hardware support table & supported architectures |
Дата | |
Msg-id | CA+TgmoaD_aMYY-eA9NZ+YTA6u=33FV-rQ=MbMktU7zJLM+y5ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Atomics hardware support table & supported architectures (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Atomics hardware support table & supported
architectures
(Andres Freund <andres@2ndquadrant.com>)
|
Список | pgsql-hackers |
On Thu, Jun 19, 2014 at 10:43 AM, Merlin Moncure <mmoncure@gmail.com> wrote: > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> 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 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. If we're pretty sure it's useless and doesn't work, so is that. But if it just hasn't been tested lately, I don't personally think that's a sufficient reason to excise it. 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 not very friendly. Of course, the risk of their platform getting broken is higher if they don't, but that's different than making it a hard requirement. We should be looking at ways to make it easier not harder for people who don't yet run PostgreSQL to start doing so. We are an open source community; we should try to be, as far as possible, open. But I think this is all a bit off-topic for this thread. Andres has already implemented a fallback for people who haven't got CAS and fetch-and-add on their platform, so whether or not we deprecate some more platforms has no bearing at all on this patch. The question that needs to be resolved in order to move forward here is this: Consider the set of platforms we support, ignoring any that don't have spinlocks. Do any of them have only one of fetch-and-add, or do they all have both or neither? If it's the latter, then we're talking about moving from a two-tiered system that looks like this: 1. No spinlocks. 2. Spinlocks. ...to a three-tiered system that looks like this: 1. No atomics at all. 2. Spinlocks but nothing else. 3. Spinlocks, CAS, and fetch-and-add. I think that's eminently reasonable from a code maintenance and developer testing perspective. It sounds like all common systems and architectures would fall in category 3, meaning that people wouldn't have to worry about (just for example) significant differences between the atomic ops supported on Intel vs. PPC. For older or more obscure platforms, categories 2 and 1 would still be there when needed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: