Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-10-28 16:06:47 -0400, Tom Lane wrote:
>> You're both just handwaving. How many is "many", and which ones might
>> we actually have enough use for to justify dealing with such a dependency?
>> I don't think we should buy into this without some pretty concrete
>> justification.
> Well, I don't think either of us is suggesting to make it required. But
> it's going to be painful to go through the list of compilers repeatedly
> instead of just adding all operations at one. I am willing to do that
> for several compilers once, but I don't want to do it in each and every
> feature submission using another atomic op.
Basically I'm arguing that that choice is backwards. We should decide
first what the list of supported atomics is going to be, and each and
every element of that list has to have a convincing concrete argument
why we need to support it. Not "we might want this someday". Because
when someday comes, that's when we'd be paying the price of finding out
which platforms actually support the primitive correctly and with what
performance. Or if someday never comes, we're not ahead either.
Or if you like: no matter what you do, the first feature submission
that makes use of a given atomic op is going to suffer pain. I don't
want to still be suffering that pain two or three years out. The shorter
the list of allowed atomic ops, the sooner we'll be done with debugging
them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
