Heikki Linnakangas <hlinnakan...@vmware.com> writes:
> ... (there's a call to _bt_relbuf in contrib/pgstattuple, but it
> shouldn't really be used in 3rd party extensions)
Meh. I wouldn't say that. I agree that the coding in pgstat_btree_page
pretty much sucks, but on grounds of lack of consistency rather than that
this shouldn't be considered an exported function. I've not checked the
commit history, but I bet what happened is that that function originally
used _bt_getbuf and _bt_relbuf, which I would say is perfectly appropriate
for something touching pages of a btree index. Then somebody decided they
wanted to make use of a BufferAccessStrategy, so they drilled down through
the _bt_getbuf abstraction layer, but they didn't drill down through
_bt_relbuf at the same time. Which is inconsistent, and could even be the
source of a bug in future if we ever made _bt_getbuf/_bt_relbuf do things
differently than they do now.
So I'd definitely be in favor of replacing pgstat_btree_page's use of it
with a direct call on UnlockReleaseBuffer; and for that matter, since it's
abandoned reliance on nbtree's buffer access infrastructure, it should
not be using the BT_READ macro either. But changing nbtree's own internal
coding patterns is a different question.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
