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 |
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 |