From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUFFER_LOCK_* synonyms |
Date: | 2015-09-16 16:30:49 |
Message-ID: | 20150916163049.GG2086@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Pedersen | 2015-09-16 16:44:21 | Re: Additional LWLOCK_STATS statistics |
Previous Message | Alexander Korotkov | 2015-09-16 16:29:59 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |