From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
Date: | 2016-04-17 17:20:29 |
Message-ID: | 11405.1460913629@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-04-17 12:01:48 -0400, Tom Lane wrote:
>> Now that I've had some occasion to look around in bufmgr.c, I am very
>> unhappy that there are still boatloads of comments talking about a buffer
>> header's spinlock, when there is in fact no spinlock anymore.
> That's actually intentional. Alexander had changed those, and it made
> the patch a good bit harder to read because there's so many references.
> As the new thing is still a spinlock, just not a s_lock.[ch] style on, I
> don't see changing all that to be a significant benefit.
Well, I disagree: we consistently use "spinlock" to mean the s_lock.h
mechanism. Lock mechanisms are important, so using the same terminology
to refer to different implementations is not helpful. Especially when
it means you have no way to talk about one implementation as opposed
to the other. Imagine writing a comment that says "back when we used
to use spinlocks for this, we had to do FOO. Now that we use spinlocks,
we can do BAR instead."
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-04-18 03:16:05 | pgsql: doc: Document that sequences can also be extension configuration |
Previous Message | Andres Freund | 2016-04-17 17:07:36 | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2016-04-17 19:28:30 | Can we improve this error message? |
Previous Message | Andres Freund | 2016-04-17 17:07:36 | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |