From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Cache Hash Index meta page. |
Date: | 2017-01-27 17:43:14 |
Message-ID: | CA+TgmoYH52vXo0+1-SdO=Wx0fRsHtufHQ_HGUv4-CHf4c67u5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 26, 2017 at 1:48 PM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> wrote:
> _v11 API's was self-sustained one but it does not hold pins on the
> metapage buffer. Whereas in _v12 we hold the pin for two consecutive
> reads of metapage. I have taken your advice and producing 2 different
> patches.
Hmm. I think both of these APIs have some advantages. On the one
hand, passing metabuf sometimes allows you to avoid pin/unpin cycles -
e.g. in hashbulkdelete it makes a fair amount of sense to keep the
metabuf pinned once we've had to read it, just in case we need it
again. On the other hand, it's surprising that passing a value for
the metabuf forces the cached to be refreshed. I wonder if a good API
might be something like this:
HashMetaPage _hash_getcachedmetap(Relation rel, Buffer *metabuf, bool
force_refresh);
If the cache is initialized and force_refresh is not true, then this
just returns the cached data, and the metabuf argument isn't used.
Otherwise, if *metabuf == InvalidBuffer, we set *metabuf to point to
the metabuffer, pin and lock it, use it to set the cache, release the
lock, and return with the pin still held. If *metabuf !=
InvalidBuffer, we assume it's pinned and return with it still pinned.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-01-27 17:49:18 | Re: sequence data type |
Previous Message | Stephen Frost | 2017-01-27 17:39:38 | Re: pg_ls_dir & friends still have a hard-coded superuser check |