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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Let's drop two obsolete features which are bear-traps for novices
Date: 2014-11-01 19:33:27
Message-ID: 9269.1414870407@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-01 19:40:47 Re: Let's drop two obsolete features which are bear-traps for novices
Previous Message Pavel Stehule 2014-11-01 19:32:15 Re: Temp tables, pg_class_temp and AccessExclusiveLocks