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

From Tom Lane
Subject Re: Let's drop two obsolete features which are bear-traps for novices
Date
Msg-id 9269.1414870407@sss.pgh.pa.us
Whole thread Raw
In response to Re: Let's drop two obsolete features which are bear-traps for novices  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Let's drop two obsolete features which are bear-traps for novices  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-11-01 15:11:40 -0400, Tom Lane wrote:
>> I don't see how HS has anything to do with this discussion.

> Consider:
> SELECT * FROM tbl WHERE active AND value = $1;
> that can be satisfied by two indexes. One on (value), and an unlogged
> index on (value) WHERE active. While in HS only the logged one will be
> used.  But if we don't silently ignore invalid unlogged indexes, hell
> will break loose after promition because suddenly the predicated index
> will be used in plans.

This example is utterly unrelated to HS: the same hazard would exist
on the master after a crash, with or without HS.

With current usage of hash indexes, nobody would ever construct such an
arrangement, or at least they would not expect to be able to start up
querying without having reindexed first.  My proposal to throw errors
was based on the assumption that unlogged indexes would only be used to
support a readily identified subset of inessential queries.  If we think
examples like the above are things people would actually want to do, then
yeah we would want to silently skip broken indexes.  I personally find
this example less than compelling and think it's far more likely that
we'll get complaints about the system *not* complaining when a broken
index would be needed.  However, it's only one line of code either way,
so I'm not going to argue about it further.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Temp tables, pg_class_temp and AccessExclusiveLocks
Next
From: Andres Freund
Date:
Subject: Re: Let's drop two obsolete features which are bear-traps for novices