|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>|
|Cc:||Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(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.|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Dec 20, 2016 at 2:25 PM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)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. But this, the way it is
right now, is just too ad-hoc, even with more comments. IMHO, anyway.
The Enterprise PostgreSQL Company
|Next Message||Ashutosh Bapat||2016-12-21 16:04:32||Re: postgres_fdw bug in 9.6|
|Previous Message||Dilip Kumar||2016-12-21 15:53:31||Re: Proposal : Parallel Merge Join|