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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Date: 2014-09-06 15:07:43
Message-ID: 20140906150743.GC20146@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Attachment Content-Type Size
hash.diff text/x-diff 4.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2014-09-06 15:17:26 Re: BUG #10330: pg_ctl does not correctly honor "DETACHED_PROCESS"
Previous Message Bruce Momjian 2014-09-05 23:02:31 Re: Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns