On Fri, May 16, 2014 at 09:45:02AM -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. 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.)
Well, at this point we are decade into having crash-unsafe hash indexes,
and rather than getting better, the issue has gotten worse with
streaming replication. If we can't find the best way to warn people,
let's find _a_ way, at least.
I feel we are waiting for the calvary to come over the hill (and fix
hash indexes), except the calvary never arrives. At some point we have
to take ownership of the situation we are in and actively do something.
If someone today tried to add a crash-unsafe, replication-impotent
index, it would never be accepted, but because hash indexes came from
Berkeley, we go with a warning in the CREATE INDEX manual page and do
nothing more. I can't think of any other foot-gun feature that is
allowed to remain with so little user warning.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
