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

On 2014-11-01 14:23:07 -0400, Tom Lane wrote:
> 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.

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