On Wed, Apr 25, 2012 at 12:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
