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

From Bruce Momjian
Subject Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Date
Msg-id 20140906150743.GC20146@momjian.us
Whole thread Raw
In response to 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>)
Responses 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
List 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. +

Attachment

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: BUG #10256: COUNT(*) behaves sort of like RANK() when used over a window containing an ORDER BY
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #10330: pg_ctl does not correctly honor "DETACHED_PROCESS"