On Wed, Dec 21, 2016 at 9:26 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 20, 2016 at 2:25 PM, Mithun Cy <mithun...@enterprisedb.com> wrote: >> -- I think if it is okay, I can document same for each member of >> HashMetaPageData whether to read from cached from meta page or directly from >> current meta page. Below briefly I have commented for each member. If you >> suggest I can go with that 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers