Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
Дата | |
Msg-id | 20160418142750.p3qwwnnuacb6n7jw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: pgsql: Allow Pin/UnpinBuffer to operate in a
lockfree manner.
|
Список | pgsql-committers |
On 2016-04-18 17:12:32 +0300, Alexander Korotkov wrote: > On Mon, Apr 18, 2016 at 2:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > > On Sun, Apr 17, 2016 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Andres Freund <andres@anarazel.de> writes: > > >> Allow Pin/UnpinBuffer to operate in a lockfree manner. > > > > > > 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. Please > > > expend some effort on making this less confusing for the next hacker. > > > Maybe make those comments talk about a "lock bit" instead? > > > > I was actually going to complain about this, too. I noticed it over > > the weekend when noodling around with another patch. I'm not sure > > exactly how it should be revised, but I find the current state of > > things confusing. > > > > +1 > Do we have consensus on renaming "buffer header spinlock" to "buffer header > lock bit"? 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). Greetings, Andres Freund
В списке pgsql-committers по дате отправления: