From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
Date: | 2016-04-18 14:58:35 |
Message-ID: | 24612.1460991515@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 18, 2016 at 10:27 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Personally I think the "spin" part is actually quite relevant, and I
>> think we shouldn't loose it. It describes concurrency and blocking
>> behaviour, and how errors need to be handled (i.e. there may not be
>> any).
> IMHO, "buffer header lock bit" is plenty clear enough. We could say
> "buffer header spin lock bit" but I think that's too many words and
> not actually more clear.
I agree. If it's just a bit, it pretty much has to be a spin lock,
because there's no way for it to contain any infrastructure that would
support anything else. In any case, you could and should document the
exact semantics in a comment associated with the declaration of that
bit field. It's not really necessary to repeat them in every reference,
so long as the references use a unique name that won't be confused with
other possible locking mechanisms. (From that standpoint, "header lock
bit" might be actively better than anything including the phrase "spin
lock", since it reduces the chance of confusion with s_lock.h.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-18 17:20:03 | pgsql: Fix --disable-spinlocks in 9.2 and 9.3 branches. |
Previous Message | Robert Haas | 2016-04-18 14:48:24 | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-18 15:04:10 | Re: Refactor pg_dump as a library? |
Previous Message | Alvaro Herrera | 2016-04-18 14:55:37 | Re: snapshot too old, configured by time |