Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
Date: 2016-04-18 14:37:25
Message-ID: 20160418143725.cpgt544cwtjftxdr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 2016-04-17 13:20:29 -0400, Tom Lane wrote:
> 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.

"s_lock.h" style spinlock vs. "BufferDesc type spinlock" etc. seems to
work. Given where vertical scalability is going (more cores, more numa
partitions (two in one socket now!), ...), it seems quite likely that
we'll end up with further special case implementations. I don't think
we'll be served well naming them differently if they have very similar
rules to s_lock.h style spinlocks.

> 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."

"Back when buffer locking used a s_lock.h style spinlock, ..., but now
that it's just a flag in the BufferDesc's state, ...".. Doesn't seem
like a problem.

Greetings,

Andres Freund

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-04-18 14:48:24 Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
Previous Message Andres Freund 2016-04-18 14:27:50 Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-04-18 14:46:21 Re: Confusing comment in pg_upgrade in regards to VACUUM FREEZE
Previous Message Tom Lane 2016-04-18 14:33:04 Re: Memory leak in GIN index build