From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: _pg_relbuf() Relation paramter |
Date: | 2015-02-04 15:40:49 |
Message-ID: | 3818.1423064449@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Lembark | 2015-02-04 15:57:03 | Re: Release note bloat is getting out of hand |
Previous Message | Tom Lane | 2015-02-04 15:23:41 | Re: _pg_relbuf() Relation paramter |