Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().
От | Tom Lane |
---|---|
Тема | Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty(). |
Дата | |
Msg-id | 10710.1405626871@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty(). (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED >> symbols. It's not like we could do anything different than >> BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it >> might make more sense to have specialized symbols, but as it is it seems >> pointless. > It's a pattern common to the index AMs. I think it's kind of pointless > myself, but as long as we're doing it we might as well be consistent. I think that to the extent that these symbols are used in APIs above the direct buffer-access layer, they are useful --- for example using BT_READ/BT_WRITE in _bt_search calls seems like a useful increment of readability. GIN seems to have less of that than some of the other AMs, but I do see GIN_SHARE being used that way in some calls. BTW, there's one direct usage of BUFFER_LOCK_EXCLUSIVE in the GIST code as well, which should probably be replaced with GIST_EXCLUSIVE if we're trying to be consistent. regards, tom lane
В списке pgsql-hackers по дате отправления: