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: 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 18:48:20
Message-ID: 8275.1414867700@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 14:39:21 -0400, Tom Lane wrote:
>> What exactly do you think is going to make a crashed unlogged index valid
>> again without a REINDEX? Certainly the people who are currently using
>> hash indexes in the way Andrew describes are expecting to have to REINDEX
>> them after a crash.

> Obviously that individual index needs to be recreated. What I mean is
> that I don't think it'll be acceptable that the table essentially can't
> be queried before that's done. The situations in which I'd found
> unlogged indexes useful is where there's some indexes are critical for
> the OLTP business (those would continue to be logged), but some other
> large ones are for things that aren't absolutely essential. Reports and
> such.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-01 18:50:27 Re: Let's drop two obsolete features which are bear-traps for novices
Previous Message Andrew Dunstan 2014-11-01 18:45:47 Re: Let's drop two obsolete features which are bear-traps for novices