Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-11-01 14:48:20 -0400, Tom Lane wrote:
>> Sure. And as long as you aren't issuing queries that would want to scan
>> the crashed index, it won't matter either way. The question is whether
>> you'd rather that your "inessential reporting queries" fail without the
>> broken index, or that they take extreme amounts of time/resources.
>> I don't think it's obvious that the first alternative is bad.
> In some of these cases the unlogged index would still be used for a
> subset of the OLTP workload, e.g. because they're smaller. We e.g. have
> a client that has smaller (as in 50GB instead of 600GB) indexes for rows
> of a certain type in the table, but also one that spans the whole thing.
Meh. There are no existing use-cases where anyone would dare use a hash
index in that way, because they couldn't be sure it would be valid.
However, it seems like we're arguing over not much. We'd certainly need a
new AM entry point to test whether the index is internally valid, so as to
support a SQL-level function that can report that. This argument boils
down to whether or not the planner should expend a few cycles to call
that, which in the end is unlikely to cost enough to notice (especially if
the AM arranges to cache that state in indexes' relcache entries).
regards, tom lane
