On 2014-11-01 14:23:07 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-11-01 13:58:02 -0400, Tom Lane wrote: > >> maybe we don't have to. What about having the init-fork mechanism restore > >> a hash index into a state with the metapage marked as invalid? hashinsert > >> etc could simply do nothing when they see this metapage state. > >> hashgettuple could throw an error saying the index isn't usable until it's > >> been REINDEXed. > > > The most annoying thing I see with that kind of approach is that we'd > > need to read the metapage pretty early during planning. > > No, I was specifically *not* proposing that. What I proposed was if the > planner picks the index for use in a query, you get an error.
Ugh. I think that'll be pretty ugly. At the very least we'd need to provide a way to mark such indexes as 'actually invalid' in the sense of indisready. It'll not only block queries that sensibly would end up using that index, but also all modifications - making the relation essentially read only. If we just want this, we can just remove the main fork of such relations on startup, and not bother with index specific stuff. > Yeah, if we were trying to duplicate the behavior of indisvalid, there'd > need to be a way to detect the invalid index at plan time and not use it. > But I'm not sure that that's actually an improvement from the user's > standpoint: what they'd see is queries suddenly, and silently, performing > a lot worse than they expect. An explicit complaint about the necessary > REINDEX seems more user-friendly from where I sit. A REINDEX is imo unlikely to be acceptable. It takes long (why would you bother on a small table?) and locks the relation/indexes. > However, if the consensus is that silently ignoring the index is the best > behavior, I would not be too concerned about the cost of checking the > metapage to see if the index is valid. A hash index's metapage would tend > to stay pinned in shared buffers anyway, because it's necessarily touched > on each use of the index. If that opinion proves wrong, the AM could take > steps to cache the state in the index's relcache entry (btree already > maintains similar cached state). We also could just put it in the generic relcache code... Yea. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
