On 2014-05-16 09:45:02 -0400, Tom Lane wrote:
> Greg Stark <stark@mit.edu> writes:
> > On Thu, May 15, 2014 at 8:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> One of the arguments against Bruce's proposal to print a warning at hash
> >> index creation is that it's a particularly ineffective form of
> >> deprecation. In your example, since the hash index was created by some
> >> app not manually, I'll bet nobody would have seen/noticed the warning
> >> even if there had been one.
>
> > I suggested we make a GUC allow_unrecoverable_indexes and default it
> > to false. If you want to create hash indexes you need to set it to
> > true or else you just get errors.
>
> I still think this is throwing the error at the wrong place. People
> will turn on the GUC the first time it gets in their way, and then
> much later discover that the index doesn't work on a slave, and we'll
> get a bug report exactly like this one.
If there's one index within many as in this case it's likely to be
accidental, right? So I think such a GUC might have helped to prevent
the problem.
> We need a check that is tightly
> connected to actual unsafe usage, rather than basically-user-unfriendly
> complaints at a point that's not doing anything unsafe. (Well, anything
> more unsafe than it ever was.)
I agree that that'd be nicer, but I haven't seen a nice proposal of how
to do that yet.
The best I can think of is to WAL LOG the removal of the entire relation
the first time a hash index is used in a session, replacing it with a
metapage that errors out when used. That should be doable.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
