I see your point, but I would like to clarify a few things.
1. Do we consider described measurement method good enough to conclude that sometimes PostgreSQL really spends 3 ms in a spinlock (like a RTT between two Internet hosts in the same city)? If not, what method should be used to approve or disapprove this?
Timing things seems fine. You may have located an important issue.
2. If we agree that PostgreSQL does sometimes spend 3 ms in a spinlock do we consider this a problem?
Probably, but then Tom didn't question 1 or 2. What he questioned was your fix.
3. If we consider this a problem, what method is considered appropriate to find a real reason of such behaviour so we could fix it?
The problem you identify is in only one place, yet your fix changes many parts of the code. Why is that the best fix out of the many possible ones? Why would such a change be acceptable?
I personally don't know the answers to those questions. It would be wonderful if somebody else would structure our lives such that all we had to do was find simple answers, but that isn't the way life is. You ask for a chain of logical thought, but it is for you to create one, somehow: patches are default-reject, not committer-explain-why-reject.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services