Re: BUFFER_LOCK_* synonyms

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUFFER_LOCK_* synonyms
Дата
Msg-id 20150916163049.GG2086@alap3.anarazel.de
обсуждение исходный текст
Ответ на BUFFER_LOCK_* synonyms  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: BUFFER_LOCK_* synonyms  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 2015-09-16 08:31:48 -0700, Jeff Janes wrote:
> All of the index methods have their own synonyms of the BUFFER_LOCK_*
> constants, for example:
> 
> #define GIN_SHARE       BUFFER_LOCK_SHARE
> #define GIST_SHARE     BUFFER_LOCK_SHARE
> #define HASH_READ      BUFFER_LOCK_SHARE
> #define BT_READ           BUFFER_LOCK_SHARE
> 
> But most of them pass their constants directly to LockBuffer.  So if they
> were ever defined to be anything else, things would fall apart pretty
> comprehensively.  (Hash index also passes them to LockBuffer, but only
> indirectly via some utility functions).
> 
> What does this pseudo-encapsulation get us?  It seems like we have a
> separation of spelling, but no real separation of concerns.

I was annoyed by this more than once too. It also bugs me that unlocking
a buffer is spelled LockBuffer(..., BUFFER_LOCK_UNLOCK) - that just
reads wrong.

FWIW, I think LockBuffer() as a extern C function is a pretty bad idea too -
it's full of essentially unpredictable branches which on the caller's
side are all constant.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: Additional LWLOCK_STATS statistics