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

Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
>> Yes, and I'm arguing that is the wrong decision.  If hash indexes are
>> "discouraged", then they shouldn't be in core in the first place.

> Last time we discussed it there were people (IIRC Andrew was one of
> them) commenting that they use hash indexes *precisely* because they're
> not WAL logged and that they can live with the dangers that creates. I
> don't think that's sufficient justification for introducing the feature
> at all. But it's nothing new that removing a feature has to fit quite
> different criteria than adding one.

> So, by that argument we could remove hash indexes once we have unlogged
> indexes on logged tables. But then there's no need to remove them
> anymore...

Yeah.  When we last discussed this, the difficulty was around how to make
that combination work.  An unlogged index on an unlogged table is no
problem: the init-fork mechanism is able to make them both go to empty
after a crash.  But for an unlogged index on a logged table, just making
the index go to empty is not the correct recovery action.

We'd been wondering how to make crash recovery change the index's pg_index
entry into not indisvalid/indisready status.  That's hard to do.  But
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.

This is not quite as nice as an indisvalid-based solution, because it
requires some extra cooperation from the index AM's code.  But setting up
an init fork requires work from the index AM anyway, so that objection
doesn't seem terribly strong to me.

Thoughts?
        regards, tom lane