On Wed, Dec 21, 2016 at 9:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 20, 2016 at 2:25 PM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
>> -- I think if it is okay, I can document same for each member of HashMetaPageData whether to read from cached from
metapage or directly from current meta page. Below briefly I have commented for each member. If you suggest I can go
withthat approach, I will produce a neat patch for same.
>
> Plain text emails are preferred on this list.
>
> I don't have any confidence in this approach. I'm not sure exactly
> what needs to be changed here, but what you're doing right now is just
> too error-prone. There's a cached metapage available, and you've got
> code accessing directly, and that's OK except when it's not, and maybe
> we can add some comments to explain, but I don't think that's going to
> be good enough to really make it clear and maintainable. We need some
> kind of more substantive safeguard to prevent the cached metapage data
> from being used in unsafe ways -- and while we're at it, we should try
> to use it in as many of the places where it *is* safe as possible. My
> suggestion for a separate structure was one idea; another might be
> providing some kind of API that's always used to access the metapage
> cache. Or maybe there's a third option.
>
This metapage cache can be validated only when we have a bucket in
which we have stored the maxbucket value. I think what we can do to
localize the use of metapage cache is to write a new API which will
return a bucket page locked in specified mode based on hashkey.
Something like Buffer _hash_get_buc_buffer_from_hashkey(hashkey,
lockmode). I think this will make metpage cache access somewhat
similar to what we have in btree where we use cache to access
rootpage. Will something like that address your concern?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com