On 11/01/2014 01:58 PM, Tom Lane wrote:
> 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?
Isn't the planner still going to try to use the index in that case? If
it's not then I'd be OK with it, but if it's going to make the table
largely unusable until it's reindexed that would be rather sad.
cheers
andrew
