Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
От | Bruce Momjian |
---|---|
Тема | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Дата | |
Msg-id | 20140906150743.GC20146@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes (David G Johnston <david.g.johnston@gmail.com>) |
Ответы |
Re: Re: BUG #10329: Could not read block 0 in file
"base/56100265/57047884": read only 0 of 8192 bytes
Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Список | pgsql-bugs |
On Fri, May 16, 2014 at 08:27:33AM -0700, David G Johnston wrote: > 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. > > 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. Here is a patch which implements the warning during CREATE INDEX ... HASH. If WAL-logging of hash indexes is ever implemented, we can remove this warning. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-bugs по дате отправления: