On Thu, Jan 26, 2017 at 1:48 PM, Mithun Cy <mithun...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
