On Wed, Apr 25, 2012 at 12:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I have no position on whether those operating systems are dead enough >> to warrant removing support, but on a related point, I would like it >> if we could get rid of as many spinlock implementations as are >> applicable only to platforms that are effectively defunct. I'm >> suspicious of s_lock.h's support for National Semiconductor 32K, >> Renesas' M32R, Renesas' SuperH, UNIVEL, SINIX / Reliant UNIX, >> Nextstep, and Sun3, all of which are either on your list above, or >> stuff I've never heard of. I have no problem keeping whatever people >> are still using, but it would be nice to eliminate anything that's >> actually dead for the reasons you state. > > The Renesas implementations were added pretty darn recently, so I think > there are users for those. The others you mention seem dead to me. > On the other hand, exactly how much is it costing us to leave those > sections of s_lock.h in there? It's not like we have any plans to > redefine the spinlock interfaces.
Well, actually, one thing I would like to do is add SpinLockConditionalAcquire(). I haven't quite found a compelling argument for having it yet, but it keeps coming up as I noodle around with different techniques to improve concurrency. I think there are some other things we'll want to add eventually, too. Of course none of that is impossible even if we keep everything, but like Peter said it saves work to not have to worry about ports that are completely defunct. I don't feel super-strongly about it, but OTOH I see little reason to keep the Univel spinlock implementation if we're removing the Univel port. If we ever decide to resupport the platform we can fish all the necessary bits out of git, and in fact it'll be easier if a single commit removes all traces of support rather than having it gradually disappear from the tree a bit at a time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
