Re: Atomics hardware support table & supported architectures
От | Noah Misch |
---|---|
Тема | Re: Atomics hardware support table & supported architectures |
Дата | |
Msg-id | 20140624170337.GA1242903@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Atomics hardware support table & supported architectures (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Atomics hardware support table & supported
architectures
|
Список | pgsql-hackers |
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 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. > > I agree that we shouldn't actively try to break stuff. But having to > understand & blindly modify unused code is on the other hand of actively > breaking platforms. It's actively hindering development. 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 otherwise change it. I favor middle ground that lets minor platforms pay their own way. Write your changes with as little effort as you wish toward whether they run on sparcv8. If they break sparcv8, then either (a) that was okay, or (b) a user will show up with a report and/or patch, and we'll deal with that. For any minor-platform user sighing now, the community offers an unbeatable deal on PostgreSQL committer time. Provide a currently-passing buildfarm member, and no PostgreSQL committer will be content until his new code works there. How can you pass that up? (By "break sparcv8", I mean a build failure, test suite failure, or large performance regression. 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.) > > 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. > > While I indeed have that fallback code, that's statement is still not > entirely true. We still need to add atomics support for lots of > platforms, otherwise they're just going to be 'less supported' than > now. Are we fine with that and just'll accept patches? +1 -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: