Re: Let's drop two obsolete features which are bear-traps for novices

Andres Freund <andres(at)2ndquadrant(dot)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.

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.

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).

> The second most
> annoying is that it's harder to for the user to detect which indexes are
> in that state - we'd probably need to provide a SQL level function to
> detect it.

Sure, we could do that.

regards, tom lane