Re: _pg_relbuf() Relation paramter

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

In response to

Browse pgsql-hackers by date

  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