Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes

On Fri, May 16, 2014 at 10:49 AM, Bruce Momjian [via PostgreSQL] <
ml-node+s1045698n5804229h23(at)n5(dot)nabble(dot)com> wrote:

> On Fri, May 16, 2014 at 09:45:02AM -0400, Tom Lane wrote:
>
> > Greg Stark <[hidden email]<http://user/SendEmail.jtp?type=node&node=5804229&i=0>>
> writes:
> > > On Thu, May 15, 2014 at 8:25 PM, Tom Lane <[hidden email]<http://user/SendEmail.jtp?type=node&node=5804229&i=1>>
> 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.
>
>
​+1

Unless there is a convincing argument to be made why doing it at CREATE
INDEX is FRIGGIN' EVIL then who really cares if its not perfect.

NOTICE: This index IS NOT WAL LOGGED and cannot be used on SLAVE servers or
AFTER RECOVERY. See Documentation for Details!

The goal should be to communicate FUD to the uninformed.

I'm all for additional and improved warnings in other places but this one
at least seems to have the benefit of being relatively simple to implement
and non-obnoxious since it only is issued once per index creation.

As devil's advocate it isn't like anyone is likely to intentionally use
hash indexes without reading the documentation first - if only to know they
exist, how they work, and what syntax to use. If an application is
installing such indexes for the user then a warning at CREATE INDEX is only
a little better than a warning in the documentation - though both are
likely to never be seen.

But that argument doesn't hold any sway for me. If someone knows they are
using a hash index intentionally then the notice/warning will be understood
and ignored while if someone is seeing the notice/warning and are not aware
of the limitations of hash indexes - like the OP - this live/logged notice
will hopefully cause them to become better informed and able to evaluate
their specific situation. If the application doesn't point out it is using
hash indexes then the typical user will not be checking PostgreSQL
documentation for the same; but just maybe the notice that is raised will
end up visible to the end-user or cause the application developers to
further re-examine their usage and/or documentation of hash indexes.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-10329-Could-not-read-block-0-in-file-base-56100265-57047884-read-only-0-of-8192-bytes-tp5804037p5804238.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.